@GhostwriterP
So from here it is up to you which has your preference, a higher frame rate or a scroll.
Another alternative: Using the scrollregister till its limit enforces a blit. So this would be a hiccup-scroller.
The pro: it is still higher fps than the normal scroller, there is a slight chance that some cam move does not hit the scrollregister limit, and finally many game seconds can go at full fps.
One could make rules that a scroll beyond scroll register limit needs "more pressure", a more urgent reason, like a man touching the border. While within the 16 pixels limit, one could follow "less urgent scroll requests".
damn, this looks realy impressive !!! There's always some slight background animation as well,
is that technically possible as well ? it's usually the kind of lame " person fistpumps" and stuff
from the crowd.I do prefer detailed and colourful fighters as shown in the demo from GhostwriterP. A colourful and animated background would be nice too but it is a secondary matter. If only one thing is possible I would choose nice characters first!
I fully agree. With few colors it's possible to make very good backgrounds, I would propose landscapes mainly. Long time ago I made some tests for a fighting game but was finally abandoned as usual... Nowadays even better, with BMP2MSX we are able to get miracles...
Cool project.. I like the scrolling !
Looks really great although the playing area is rather small. Nonetheless a great tech demo! Congrats.
The scroll mode has a lot of advantages, being a lot easer for one, but in the end a higher frame rate is likely preferred and thus the game area could be as big as the screen (no scroll than obviously).
Like Fighters Ragnarök but then with slightly bigger characters
In R800 mode, msxTR has an HW delay of minimum 52 R800 cycles between successive outs to the VDP ports
For this reason, on TR, modes using the HMMM commands can be faster than modes where the CPU does the copy
It is matter of:
1) lenght of the horizontal chunks: longer they are faster is the VDP agains the CPU
2) overhead on sending commands: using final values from the previous command an horizontal chunk can be copied setting just 4 registers i.e. 7 outs
- sx -> no need : just left allign all slices
- sy -> no need : sy->sy+ny
- dx -> 2 outs
- dy -> no need : dy->dy+ny
- ny -> 2 outs
- nx -> 2 outs
- R#46 -> 1 out using R#17
total 364 R800 cycles/slice
I'm sure that the technique is competitive wrt mode 4 (at least for large enemies)
The above evaluations do not hold in z80 mode or on plain msx2/msx2+, where vdp and cpu should have about the same speed when filling vram areas
I faced the issue in the raycasting project (www.msx.org/forumtopicl12727.html) where Wouter pointed out this important flaw in the msxTR design
The delay is emulated both by blue and open msx
I think it will always be slower. In mode 4 we restore the background and copy the new frame at the same time. You are right that for larger sprites the above could pay out, however the turning point is, I think, above the 'big sprite' sizes. And at that point the frame rate will have dropped below 20 fps either way.
I'll settle for a game like "street neo fighter" with all characters.