That's what I'm saying, it's too slow. Look at the Ys series, it's not full screen but it's already too slow.
It does not need to be super fast and smooth. look at nemesis or gradius, even if they were able to do fast scroll due to tile mode the number of scrolls x seconds is very low.
This approach does waste a lot of cpu/vdp time trying to update the screen with tile approach, so it does send a lot of small vdp commands.
the screen size is not a critical factor here, the critical factor is HOW MANY TILES CHANGE between one "rendering" and the next. One could have a small screen size but with a lot of changes and perform worse than a bigger screen with a lot of unchanging areas.
this approach works fine only if the screen does not change at all in bigger areas, otherwise not.
With the "differerential tile update" approach you loose a lot of time in:
- Comparing if a tile has changed or not (Z80)
- If Changed, calculate the SX, SY, DX, DY parameters (Z80)
- Send a command to VDP, waiting if it was not busy in previous operations (Z80)
- Next the vdp need some extra time, once command is issued to take in charge
- Usually the command is a 8x8 command block. Here the vdp loose a considerable efficiency in doing the command....
You don´t want to use R#18 register to create the scroll effect and yet you want scroll that is smoother than 8x8 in SCREEN5, no matter how slow. OK, let's go with that.
You talk about tiles, but there are no tiles to consider, since SC5 is a bitmap mode. You can't even talk about pseudo-tiles aligned inside a lattice since you don´t want to use R#18. So you have to REDRAW all the graphics shifted a few pixels left or right each frame in another page in order to hide the slowness of HMMM. So doing that throws away the idea of only updating the tiles that changed since there are no tiles to begin with and the next frame is completely different from the previous one.
Even so, you could probably ignore updating some areas of the screen, but only the most basic single colour block regions. And you will still need to remember to update their intersections.
{moderator alert: please watch your language. insulting other people is not tolerated}
Ok, i see you do not miss any chance to show us your incompetence. ;-) ;-)
You don´t want to use R#18 register to create the scroll effect and yet you want scroll that is smoother than 8x8 in SCREEN5, no matter how slow. OK, let's go with that.
You say this. Not me. I'm only saying if a brute force scroll via hmmm copy command is faster than the tandy.
No R18, No Smooth Scroll (meaning scroll at 1px steps).
You talk about tiles, but there are no tiles to consider, since SC5 is a bitmap mode.
Wow, what a revelation! We all thank you for this ! It's a thing that no one didn't know.
Obviously, as we all know, (except you?!) the majority of YS-like games treat the screen as if it was made up of tiles, pratically emulating the nametable, (one can call this sw tiles) then they render each changed tile between one frame and the next via vdp copy commands as i've already described. (There are a *lot* of games using this approach or variants of it)
So your previous sentence proves only that you have not understood anything .
And based on my previous post, it is clear that i mean this, as is absolutely clear by my description of the rendering process when i talk about calculations and vdp commands. ;-)
You can't even talk about pseudo-tiles aligned inside a lattice since you don´t want to use R#18. So you have to REDRAW all the graphics shifted a few pixels left or right each frame in another page in order to hide the slowness of HMMM. So doing that throws away the idea of only updating the tiles that changed since there are no tiles to begin with and the next frame is completely different from the previous one.
As said, you forgot a little thing. I've never mentioned that i want smooth scroll (in the meaning of 1px scroll) , instead i've mentioned the most classical way, the YS way, that of course is not smooth at all.
this make all you considerations not applicable as the scroll work in this approach at 8px steps (one tile)
gdx and metalion already understood what i meaning because they mentioned Ys and screen 4 (which is a tile mode) when replying to me
Obviously, you have serious problems in understanding my post. ;-)
I call upon the moderators to please do something about this. This person is not interested in a civilised conversation.
sigh.... dude..... take the high ground
Personally I think I don't care much about a scrolling VK. It's not like the current VK is very annoying, neither are other page-per-page games like Metal Gear, Usas, Goemon and many others. Smooth scrolling becomes a bit of a thing for games that scroll by nature, yet do it in a jerky way because of limitations (Nem123ParoSala).
I call upon the moderators to please do something about this. This person is not interested in a civilised conversation.
maybe you best try to understand better instead of making post with the intent of ridicolize others.
With you post you failed your intent and the only thing you got was to show that you have not understood anything.
We have already seen your approach in a previous post with gdx where you kept replying to it in a non costructive way by mangling its previous posts.
So, do not complain if someone will reply you in a ironic way by screaming at moderadors with the argument of " a not civilised conversation".
Personally I think I don't care much about a scrolling VK. It's not like the current VK is very annoying, neither are other page-per-page games like Metal Gear, Usas, Goemon and many others. Smooth scrolling becomes a bit of a thing for games that scroll by nature, yet do it in a jerky way because of limitations (Nem123ParoSala).
I think the tandy xt scroll is not at 1px steps. I clarify another time my question:
It is possible, using a crude VDP command to get a better result in terms of fps than tandy ?
For crude VDP command i mean a combined approach were:
- you do the main scroll with a single big hmmm copy command, scrolling the entire width of the screen minus 8px of the 'incoming' part (during the scroll)
- you draw the incoming part using some kind of vdp command or z80 to fill in the incoming part
from my estimations i figure that maybe one can reach 6-7 fps but i'm not able to estimate the tandy fps.
maybe you best try to understand better instead of making post with the intent of ridicolize others.
You should try to understand better the points @pizzapower was making instead of being ironic and hostile. Could you please indicate where anybody tried to ridicule someone else? And perhaps if you took more care and consideration in better explaining your own points you wouldn't need to complain about not being understood.
maybe you best try to understand better instead of making post with the intent of ridicolize others.
You should try to understand better the points @pizzapower was making instead of being ironic and hostile. Could you please indicate where anybody tried to ridicule someone else? And perhaps if you took more care and consideration in better explaining your own points you wouldn't need to complain about not being understood.
I've already observed pizzapower approach in a previous post:
- He start to trying to contest another post, (from now the target) by ridicolizing it.
- Then the target will reply, initially in a gentle manner
- The He keep replying in the same way, mangling the posts of the target
- When/If the target reply in a less gentle way, it starts screaming at moderators as the attacked person. The poor victim. {mod: please stop}
As for clarity of my post it is clear enough as we can see from comments of "gdx" and "metalion" proved they have understood correctly the contents.
So, i think the post was clear, and i recommend pizzapower to read it with more attention in order to avoid misunderstanding and replying (with obvious explanations about VDP video modes that everyone here knows) in a no-sense way as it did.
