Remaining VRAM in screen 8

Por megatron-uk

Resident (51)

imagem de megatron-uk

21-02-2022, 09:34

I am putting together the building blocks of a multi platform RPG engine that is going to be somewhat of a hybrid between an old style text interface somewhat like an early title like The Bards Tale, with a more modern turn based jrpg combat engine.

Yes, a little bit of an odd combination!

Anyway, with the MSX(2) target I'm going to be using screen 8; 256x212, rgb332. My 'sprites' are simply bitmaps and since I am not needing collision detection or fast animation this should be fine - all combat will be resolved using 5th edition D&D rules.

128kb VRAM will be a minimum and 256x212 uses slightly less than one page. My question is - are there any restrictions on the remainder of the available VRAM? The 'sprite' frames I've calculated to take up the entirety of the second page:

There are two possible combat scenarios;

1. 4x Player characters + (up to) 6 Enemy characters:

3x idle frames
2x attack frames
1x damage frames
1x backbuffer frame to store BG on sprite movement

These are all sizes at 32x32px.

2. 4x Player characters + (up to) 2 Enemy characters + 1 Boss character

As above, but Boss is 64x64px.

In both situations I would use 64kb of the second page, or just under. Is that possible? (I.e ignore sprite and palette table - the latter of which is not used in the screen 8 332rgb mode.

Secondly, can the remaining "off screen" vram in the first page still be used (I am thinking for things like UI elements, hit effects etc). Basically I don't want or need an hardware sprites at all - so can that space be used fully, or is it always reserved?

Entrar ou registrar-se para comentar

Por megatron-uk

Resident (51)

imagem de megatron-uk

21-02-2022, 09:40

This will be in C, btw, using z88dk and the vdp functions pulled from either fusion-c or msxgl.

Por ARTRAG

Enlighted (6977)

imagem de ARTRAG

21-02-2022, 11:06

You can safely disable all HW sprites by setting bit SPD in R#8. The area under the border can be used to store bitmaps. I suggest you reduce the visible screen to 192 lines by setting bit LN in R#9.
In this way you get 64 lines under the border (instead of 44) and you can fit 2 lines of 32x32 frames (8+8=16 frames).

If you plan large animations, you could need to resort to double buffering if you want to avoid frame tearing (wasting the second VRAM page).
Anyway for the kind of game you are planning, probably the game will look fine even without double buffering and you will have a big speed benefit by storing up to 64 frames in page 1 and up 16 frames under the border of page 0

Por Grauw

Ascended (10821)

imagem de Grauw

21-02-2022, 11:34

If your game is in ROM format, you can also consider to stream the (soft)sprite frames from ROM with the HMMC and LMMC commands. It comes at the cost of CPU power, but then you are no longer restricted by available VRAM.

Por megatron-uk

Resident (51)

imagem de megatron-uk

21-02-2022, 15:15

I am planning on a MSX-DOS games, since I have been conversing with the z88dk contributors and they have implemented a proof-of-concept banking scheme using the MSX-DOS2 mapper entry points.

I am trying to keep most of the back end code platform agnostic - the loading of map locations, enemies and items, story text etc, so am trying to keep all of the platforms disk based (also one of the main aims of the project is to build a runtime engine that plays a different game just by swapping the data files).

I'm some respects a ROM target would be easier, but some of my intended targets don't have it as an option.

I didn't consider reducing the vertical display size to claw some space back for additional assets, but that's well worth consider now that you mention it.

Por ARTRAG

Enlighted (6977)

imagem de ARTRAG

22-02-2022, 08:59

Look at http://m.gr8bit.ru/gr8bit-knowledge-base.html
For the
V9938-programmers-guide.pdf