MSX 1 smoothscroller general purpose engine

Страница 2/7
1 | | 3 | 4 | 5 | 6 | 7

By hit9918

Prophet (2868)

Аватар пользователя hit9918

09-05-2010, 13:39

why not moving to a megarom with any mapper you like?

oh. I haven't thought of that. The issue is I want to do things possible on real MSX.
And Nemesis 2 is possible on real MSX. On the other hand I cannot make my own Nemesis 2
and then load it to my real MSX.

I feel like giving away a 64k MSX and getting back a 24k console capable of scrolling.

btw, another thing todo is to have interrupts possible in the slot view of the scroller.
And then insert SAVE SP, EI, DI, RELOAD SP sections into loops of draw and runcmd,
because else those stackpointer abusing codes cause too much latency for the sprite
code in interrupt server :\ I want sprites and the whole game fullframerate even
when scroller stalls to 16fps.


if the prerotated tiles have to stay in the z80 memory to be loaded in vram when needed the best thing is to devote some pages in a megarom mapper (I like konamy scc, but any other is good too).

btw cardridges got their own slot methods?
Isn't there a standard way to make subslot cartridges in MSX from day one?
I was always suspicious about that FFFF location, is it wired to anything in my Hit Bit 75P ?
Are there machines where FFFF just ends up in the normal RAM cell? Are there machines that cannot do subslot cartridges?


Consider that working with magarom allows you to use all the RAM you like (you can use the disk drive ram as you like).
Moreover, you can arrange tiles and megarom pages in order to acces to a potentially unlimited number of prerotated tiles. All you need to have handy is a table that tells for each tile what is the page and the address to set in order to get the data.
Do you agree?

No changes of the core data structures needed, only a change in glue code: there are 8 bitmaps, and glue code does provide runcmd loader with an address: see the patternarr[X&7] + (Y&7) kind of codes. [X&7] does select one of 8 bitmaps.

You would just need some struct array slotselect[8] and then enable slots from slotselect[X&7] before the call to runcmd.
So the far addresses would be a combination of patternarr[]/colorarr[] and slotselect[]. This requires that one bitmap can
be fully visible at the same time.

By MäSäXi

Paragon (1884)

Аватар пользователя MäSäXi

09-05-2010, 13:50

I feel like giving away a 64k MSX and getting back a 24k console capable of scrolling.

I like that. Smile

Losting 40 Kilobytes is a lot, but good programmer+designer can make a good game into existing 24 Kilobytes too! Smile

Remember, many good 1980s games fitted into 24K or less, on other eighties 8-bit platforms too! Smile

Thought there´s less space for musics then. Wink

By GhostwriterP

Champion (511)

Аватар пользователя GhostwriterP

09-05-2010, 14:42

Sounds all nice but I can not shake the thought that 16 tiles can already produce 256 tile combinations were you can have only 128 tiles available due buffering. It is far more limiting than at first look is it not?
Especially for diagonal scrolling.

By hit9918

Prophet (2868)

Аватар пользователя hit9918

09-05-2010, 14:52

@9918: good work, really: is there a way to half the tiles by using a 2px scroll step?

nooo nooo nooo this is absolutely impossible, because... puhlease don't do this Wink Tongue

The demo scrollspeed is 1 pixel per frame, but it needs 2 frames, so you are already seeing 2 pixel scroll steps.
However when there are bitmap rich 3 frame passages, having only 2 pixel granularity scroller would be worse.
I am afraid that a jump game would lose accuracy if you reduce to 2 pixel steps.
On the other hand a Gradius going along 25Hz in 2 pixel steps sounds ok.

BTW I favour games that are same speed on PAL and NTSC. Then again you want 1 pixel granularity for things to not look worse, because you would have odd scrollspeeds like e.g. 1.5 pixel per frame.

But. Again the whole thing is just a matter of small changes in the glue code and nothing in the core parts.
Remove the loads of the odd bitmap/color files like .pa1 .co1 .pa3 .co3 ... (the entries in loadinfo[] array).
Now the remaining files can be twice as big (the number at the end tells the scroll position of the graphics).

Then use [X & 6] instead [X & 7] in the bitmap selecting codes. I.e. now the odd entries of patternarr[] and colorarr[] are disabled/invalid.

So now you get twice as much graphics. And only 2 pixel scroll steps. I feared this request would happen.
I wanted it to be like NES Wink needs more hardcore programming, todo is

speed: another draw function that does not allocate for the frames where it is not needed

mem consumption: a rewrite of engine and compressor to a stuct that instead of the int bitmap got separate
int pattern and int color offset, so colortable can compress separately, I think often colortable
could crunch down much better (e.g. Nemesis 1 Moai got a lot color 4 + 5 chars and the rocks are all color 9 + 1).


i do not remember if the sprite bug also appear when using the 2/3 name table trick. If not, one could use a single charset for first two parts of screen in order to conserve memory.

no, dealing the 3 vdp charsets is only a speed issue and never a mem consumption issue!
the 3x split happens only in VRAM, not in the RAM bitmaps of the engine.

the easiest way to see more speed is to change for (i = 0; i < 3; i++) to for (i = 0; i < 2; i++)

(make sure you do this in test8() because a whole different engine code is lurking in the sources)

running only the upper 2/3 of the screen the draw needs only do 512 instead 768 bytes,
additionally no loads to third charset need to happen. now make a panel in lower third of
the screen that does hide as much as possible the impression that you did snip something.
I think leaving lower 2 or 3 rows of the panel blank is a good way to do this.

I made the demo to show the full thing, fullscreen 1 pixel diagonal scroll, and there are multiple ways to cut things down. Many tradeoffs between a bitmap rich Knightmare scrolling slowly vertical-ONLY and a scare bitmap horizontal fullframerate action game. Everything works with just a change in the glue code. Except the separate colortable compression idea which needs changes in both engine and compressor tool.

Oh, NOTE: if you do a horizontal-ONLY scroller, set Yscroll variable to 0 in compressor tool and it will compress better!
(see README.txt). Because diagonal scrollers got the worst neighbour-tile dependancies in two dimensions (it was horrors to write the tool). If you take horizontal-only compressed graphics and try vertical scroll, you will get corruption surprises.

By hit9918

Prophet (2868)

Аватар пользователя hit9918

09-05-2010, 15:12


I like that. Smile
Losting 40 Kilobytes is a lot, but good programmer+designer can make a good game into existing 24 Kilobytes too! Smile
Remember, many good 1980s games fitted into 24K or less, on other eighties 8-bit platforms too! Smile

Well 8 of the 40k are stolen by BIOS Crying I give away an 80K MSX and get a smoothscroller MSX console with 24k RAM and 16K VRAM Smile Plus 4k bitmap-only RAM in horizontal scroller screenmode Wink But the numbers are not fix as one can trade bitmap versus the rest.


Thought there´s less space for musics then. Wink

How much does a typical Nemesis soundtrack take, any figures?

By hit9918

Prophet (2868)

Аватар пользователя hit9918

09-05-2010, 16:40

Sounds all nice but I can not shake the thought that 16 tiles can already produce 256 tile combinations were you can have only 128 tiles available due buffering. It is far more limiting than at first look is it not?
Especially for diagonal scrolling.

You are right on this.

Best case is like "Nemesis 1 Moai Level style". Or even better is the Nemesis 2 Level 1 Mask. it got like 4x8 chars, and diagonal scroller needs 5x9 chars.

And worst case is Turrican style "everything made of neat little 8x8 tiles placed randomly next to each other", it will make memory explode.

Games that work:

Knightmare. The gfx on the left and right side is in the style "same object repeated, plus a head and a tail, and no random puzzeling". This works with small overhead. And vertical-ONLY scroll the engine can give you a huge 32k charset, so actually in vertical scrollers you tend to have MORE graphics than VDP native, if the style is not "everything puzzled from little 8x8 tiles in random order".

Ghost n Goblins, which my sketch does mimic a bit, and it even got almost something like a Sega Alex palm tree (well that is what the programmer wanted to sketch Wink

As you said "it is more limiting than the first look" - But that first look was not on a mockup gif, but a level that really worked in the MSX.
So the task would be to do something that looks like e.g. the diagonal scrolling Nemesis 1 on the NES - in the first look Wink Wink
I am not saying you said anything wrong, but the possibilities vary strongly dependant on graphics style.

On a sidenote, the color dots tile got 8 different colors, actually 9 including black - this tile is much better than the 4 color NES Wink
The C64 was hacked hell a lot. The other computers were not (except maybe ZX).
Hack 9918 a lot and in some parts it might even be better than NES.
If you do not want to be attacked by hacking surprises, need to go vertical-only scroller.

By ARTRAG

Enlighted (6250)

Аватар пользователя ARTRAG

09-05-2010, 18:54

Think about megarom
almost all the current developmnets are done for megaroms
this solves all the rom explosion you asy
Actually you canb limit the impact of your tecnique to a 8K window in a larger rom size

By MäSäXi

Paragon (1884)

Аватар пользователя MäSäXi

10-05-2010, 08:42

Artrag, Hit9918 especially wants to make it possible to run smoothly scrolling game on MSX-1 without megarom. Smile

But nice idea otherwise. Smile

By the way, is it possible to calculate existing PSG tunes´ memory eating from the game music files used in Yawara PSG player? Smile Thought I don´t remember surely, if it had Nemesis tunes or not. But many other tunes it has. Smile

By ARTRAG

Enlighted (6250)

Аватар пользователя ARTRAG

14-05-2010, 08:24

hit9918, is it possible to adapt the development tools to something not needing java and sdcc ?
do you have plans for using this tool in a real msxdev entry?

By hit9918

Prophet (2868)

Аватар пользователя hit9918

22-07-2010, 05:49

hit9918, is it possible to adapt the development tools to something not needing java and sdcc ?
do you have plans for using this tool in a real msxdev entry?

sorry for late answer!
I got no msxdev plans and everyone can use the code.

Страница 2/7
1 | | 3 | 4 | 5 | 6 | 7