have you made up what screen mode you are gonna use in the final version?
msx1/msx2?screen2,4,5?
ive been downloading some songs of Gng.
I really feel like making a cool version for msx !!
^_^

@norakomi:
Good! if you do some songs can you do for the psg only?
If i have time to start my gng version for msx2 i will be very happy to use them...

norakomi: by the way, what is the status of Manbow 2?

Quote:

So, why didn't Konami use those techniques in their Nemesis saga shooters?

Quote:

Because it limites severely the number of colors managed in the tiles.

If konami only forced the user to turn the monitor on it's side

Quote:

Erm...not really 8x1, it's more 24x1 pixels or something like that I guess that every 3 chars a scrolling tile is defined...

The requirement is really that for each 8x1 block, there can only be two colors in a (16-n)x1 superset block, where n is the #pixels to scroll each time.

This is why there must be at least 7 black pixels around the ladder or the water or the house. As long as the neighbouring tiles have the same colors, you can look at it as 8x1 block gfx.

Hi Daniel,
first of all, greetings to you and to Viejo_archivero for the brilliant graphic/code proposed.

I see that your code rotates in REAL TIME, bit per bit, the definition of a bunch of tiles (the core of your algorithm is 3 rrca - basically).

I have one question/proposal:

Assume to use, as Viejo_archivero did, a step of 2 pixels for the scroll...

If you store in RAM the rotated versions of your tile set, you need only 4 X 2K = 8K (or if you use only 128 tiles, 4 X 1K = 4K)

Assuming that you precompute the tile sets in RAM, 8K, (or better 4K) can be considered a fair small amount of RAM to be devoted to the scrolling.

The advantage is that you get a HUGE speedup in the code, that at each step, needs only to update the tile set (i.e. to move to VRAM 2K -or 1K for the 128 tile version) and eventually to update the PNT (768 bytes extra).
What do you think? Wouldn’t this be the definitive solution for the CPU load?

I actually use pre-rotated images already. Its about 100 tiles but compressed they and the patterns and the code all fits in an 8k rom.

The routine updates all 100 tiles every frame though, also the ones that aren't visible. But the final version of the scroll engine is supposed to support up to 256 tiles in a game level and 75 or so visible at the same time. But the tile allocation and switching is not implemented yet.

Using 2 pixel scroll at 25fps would free up a lot of CPU time to other tasks. Now about 40% CPU each frame is used to update the tiles in VRAM and another 30% every 8th frame for updating the pattern table. But even with a 1 pixel scroll at 50fps, it should be enough CPU time left for the game logic.

I see.
BTW have you ever noted that in VRAM there is plenty or spare room for storing extra tilesets that CANNOT be used by the VDP
due to the crappy management of the start address of the Pattern Generator and Color Tables in screen 2 ?

Actually, using the "hybrid" bank modes, you need only 2K+2K data in VRAM for rendering the screen,
thus, in theory, you could store up to 8 extra tile sets in VRAM (PGT only, all banks sharing the same colors).

If only we could move the PGT start address, we could select on fly the tile bank, with almos zero CPU load!!

Are we sure that there is no HW trick to set the PGT address in positions different from 0 or 8K in VRAM?
Some other "hybrid mode", or undocumented feature of the TMS ?

The other option, sadly, is to use screen1, where you can actually store all the tilesets in VRAM and
switch on fly among them only setting R4...

The pros are that you can have really up to 8 tilesets with almost zero CPU load
The cons are that you get the color limitations of scr1 (with results very ZX like)

BTW
staying with the feet on the floor, let's go back to your demo
you could split the tiles of the screen in two parts,
e.g. 64 tiles are updated realtime as you do now and 32 are stored in VRAM in the active (AFAIK unique active) tileset as 4x32=128 prerotated tiles

This is a midpoint between yours and vejo's solution, that for what i can see stores all the prerotated tiles in the active tileset

To do GnG we need a multi directional scroller though and I wonder if its possible to do a multi directional scroller that is tile based. I think viejos scroller is multidirectional but I'm not sure. Mine isn't and was really designed to do very smooth 1-pixel horizontal scrolling only. I've been working a bit on a multidirectional scroller too but I don't have anything ready yet.

Btw, I fixed the problem with running the GnG demo in 60Hz. If you are interested you can download the update at:

http://www.bluemsx.com/demos/gngdemo3.zip

Now it is using 20% updating the 100 rotated tiles and 30% every 8th frame for the pattern table (in 50Hz). So its quite efficient and leaves plenty of CPU time for other things.

I was actually planning of doing tile banks or something similar. The idea is that only 100 tiles can be shown and updated at one time. For this part of the game it would improve things quite a lot since you could add more details to both the first half of the game and the last half with the forest and the house. So in total there can be 256 tiles per level which should be enough to do quite good details.

The problem is combining the quite nice horizontal scroll with a vertical pixel scroller.

Quote:

Mine isn't and was really designed to do very smooth 1-pixel horizontal scrolling only

I think that the scroll speed must be of 1-pixel or equivalent, say 2-pixels at 25/30 fps like viejo's one. Could afford the tile routine the vertical scroll?, there're tons of tiles involved...
The only pro I can see about the v-scroll is that the horizontal edges between surfaces are more commonly black tile-filled tile than in vertical edges; so it seems less tricky to avoid color conflicts here.

In the worst case, the Amstrad scroll technique could be used...

Quote:

@norakomi: Good! if you do some songs can you do for the psg only? If i have time to start my gng version for msx2 i will be very happy to use them...

Ow, Im sorry. I can only use SCC-Blaffer, which uses the 5 scc channels for music, and the psg channel for drums. That (and SEE) is the only program I can work with.
Sorry.
So, I can only make scc music, no psg.

Quote:

norakomi: by the way, what is the status of Manbow 2?

It's done !!! We're testing it now.
I've got this super irritating bug, that you just die sometimes without a reason.
Maybe a bug in the collision detection. I havent figured it out yet.
but all the levels, demos, music etc etc. All done.

So as soon as you fixed the bug we have a downloadable promo?