Smooth scrolling

[sometimes99er]

I use the undocumented backdrop plane :-) No really, ...

 

And of course the transparent color, which usually just sets us through to the screen color or should I say the background color, was a chip genlock feature. So you could have a, documented, see-through backdrop. I guess the result would be slightly fuzzy (from what I've seen from the day), but did one or two arcades actually use video chips genlocked ?

 

The stars seem to "suffer" from "shadows", but that really doesn't matter. I guess one could workaround that too. I suspect you could ease a bit on the cycles if you made more simple graphics - which might ruin it all. Do you scroll all possibilities or only those in view ?

 

[marc.hull]

It's 100% assembly language. I can't imagine how this would be possible compiled basic!

 

Sorry, I got thread confused. Of course it's machine code, no offense intended.

 

I'm thinking about turning it into a game, of course, but there are some problems: 1. Apparently you can only rely on 8 sprites working in this mode because of a weird bug, but I could choose to ignore that. 2. I think a have almost run out of clock cycles. To make this a game I would probably have to limit the scrolling to every second frame, but that might not be so bad. 3. Time... I have 3 small children.

 

8 Sprites may not be so bad with some clever planning. Does your code run free or is it paused by the VDP cycle ? If so remove your trigger and let it run wild. Maybe it will suprise you how fast it is occuring, maybe not. At any rate it looks really nice and thanks for taking the time to do this. I hope you take this to completion.

[slinkeey]

Apparently you can only rely on 8 sprites working in this mode because of a weird bug, but I could choose to ignore that.

 

F18A?

[Asmusr]

Sorry, I got thread confused. Of course it's machine code, no offense intended.

Only slightly offended, more shocked :-)

 

8 Sprites may not be so bad with some clever planning. Does your code run free or is it paused by the VDP cycle ? If so remove your trigger and let it run wild. Maybe it will suprise you how fast it is occuring, maybe not. At any rate it looks really nice and thanks for taking the time to do this. I hope you take this to completion.

 

It's waiting for vsync. It doesn't make much difference if I remove the wait loop - at least not in Classic99 - which is why I think there's not much time left. I also tried using the debugger to check it, but the results were confusing.

 

I think the solution is only to scroll every second frame but to scroll 2 or 4 pixels at a time to obtain the higher speeds. The video is only 15 FPS so it would still look better than that. This would require some modifications to the way my algorithm updates the double buffers, so I haven't tried it yet.

 

Regarding the sprites I could use the first 8 for the ship, shadow, bullet and 5 enemies. The remaining sprites could be used to add more colors if an F18A or an emulator is detected (is it possible to detected an emulator?).

[Willsy]

Just wondering why there's an 8 sprite restriction? Is it something to do with the location of the various VDP tables in VDP memory?

[marc.hull]

Only slightly offended, more shocked :-)

 

 

 

It's waiting for vsync. It doesn't make much difference if I remove the wait loop - at least not in Classic99 - which is why I think there's not much time left. I also tried using the debugger to check it, but the results were confusing.

 

I think the solution is only to scroll every second frame but to scroll 2 or 4 pixels at a time to obtain the higher speeds. The video is only 15 FPS so it would still look better than that. This would require some modifications to the way my algorithm updates the double buffers, so I haven't tried it yet.

 

Regarding the sprites I could use the first 8 for the ship, shadow, bullet and 5 enemies. The remaining sprites could be used to add more colors if an F18A or an emulator is detected (is it possible to detected an emulator?).

 

You can use the 9901 to time your loop. It will measure well past the time of a VDP interval. Code and examples are on Theirrie's site. Maybe that will give you a bench mark. One word of warning. Be carefull when switching 9901 modes that you give the 9901 plenty of time to settle it's I/O lines or you will fry it. Not a problem on emulators but You would hate to cook someone's console with a demo ... When writing the SID Player I ruined 2 9901 ICs before I found out what was happening. At any rate this will give you a reasonably precise amount of real time your code is taking to execute and thus a good picture of where you stand. Good luck !

[Tursi]

Just wondering why there's an 8 sprite restriction? Is it something to do with the location of the various VDP tables in VDP memory?

 

It's a bug/feature in the VDP.. when name table masking is activated in bitmap mode, sprites after the first 8 start to ghost and truncate in interesting but not-fully-understood ways. I demonstrated this in a video here:

(skip to about 8:15).

 

[youki]

 

I'm thinking about turning it into a game, of course, but there are some problems: 1. Apparently you can only rely on 8 sprites working in this mode because of a weird bug, but I could choose to ignore that.

 

 

I got this problem on my first dev on colecovision few year ago.

 

here the solution , i found (with the help of some atariage members! )

 

http://atariage.com/forums/topic/143304-did-you-have-problem-on-real-console/#entry1752992

 

[Opry99er]

Sprite cloning, eh? That's a trip... =)

 

Looks like you guys figured out a workaround?

[Asmusr]

I got this problem on my first dev on colecovision few year ago.

 

here the solution , i found (with the help of some atariage members! )

 

http://atariage.com/...e/#entry1752992

 

 

Thanks, but it looks like the solution is to use full bitmap mode, which is not an option because I would need send three times more data to the VDP to update the pattern tables (note that I need to do this for every frame). Or perhaps I'm missing the point?

[Asmusr]

Do you scroll all possibilities or only those in view ?

 

I scroll all the used tile transitions, also those that are not currently in view. If your map is very heterogeneous I think it could make a big difference only to scroll the visible tiles, but the algorithm to determine if a tile was visible would have to be really efficient. Having to run through a list of row intervals for each tile would probably be slower than scrolling everything. Any ideas?

[Opry99er]

Do you have a fixed width? Maybe the width of the screen? Or is it wider than what is visible onscreen at any time?

[sometimes99er]

I scroll all the used tile transitions, also those that are not currently in view. If your map is very heterogeneous I think it could make a big difference only to scroll the visible tiles, but the algorithm to determine if a tile was visible would have to be really efficient. Having to run through a list of row intervals for each tile would probably be slower than scrolling everything. Any ideas?

 

Now that you said that cycles were tight, it would make sense, at least if you scrolled continuously through different terrains. Otherwise the idea would maybe be massaging data beforehand, not at runtime. A bit like when you pre-analyzed what scrolls into which.

 

Analogy. I seem to remember, back in the Amiga day, and all through to present day, that compressing files could be something that could take a long time (deep optimization or something), but uncompressing was always fast and sometimes even simple. I’ve seen it a few times with demo stuff for 8-bits. Compressed on present day machines, high compression rates, but uncompressing just fine, quite speedy and surprisingly simple code on 8-bits.

 

[Opry99er]

I don't know if this is a worthwhile analogy, and forgive me if I am not on your level, but the COMPRESS function in XB256 definitely decompresses quite quickly. I realize it's XB and this project is pure 9900 asm, but it would seem like compression of the terrain would be a way to decrease cycle time. Even using a decompression algorithm at runtime would seemingly take fewer cycles than scrolling the entire "map" data-set each time.

 

As I said, I may be out of my league here, but what sometimes99er said makes perfect sense and using XB256's COMPRESS feature as an example, I would venture to guess that you could pick up some speed here.

 

Of course, a benchmark test would seem to be in order. =)

[Asmusr]

It's a bug/feature in the VDP.. when name table masking is activated in bitmap mode, sprites after the first 8 start to ghost and truncate in interesting but not-fully-understood ways. I demonstrated this in a video here: https://www.youtube....jSJqzDR0 (skip to about 8:15).

 

Do you still have the source code you used for your video available? I would like to test if changing the location of the sprite tables in VDP RAM makes a difference. I would also like to try it on my PAL console. Thanks.

[youki]

Thanks, but it looks like the solution is to use full bitmap mode, which is not an option because I would need send three times more data to the VDP to update the pattern tables (note that I need to do this for every frame). Or perhaps I'm missing the point?

 

Not exactly the full bitmap mode. My solution still use only one color table not 3. But it uses 3 pattern tables instead of one .

[Asmusr]

Not exactly the full bitmap mode. My solution still use only one color table not 3. But it uses 3 pattern tables instead of one .

 

I see, so you would only have to double the amount of data rather than treble it. That's actually something to consider. And there are no issues then with any of the sprites?

[youki]

I see, so you would only have to double the amount of data rather than treble it. That's actually something to consider. And there are no issues then with any of the sprites?

 

Nothing i noticed. I use sprites intensivly in my games and i have no issue now.

[youki]

Just a side note.

 

in case of the colecovision, this mode is not supported by all the emulators. Colem on Nintendo DS for instance does support that mode , the result is that you have the rigth colors only on the top part of the screen. The 2 others part are black and white .

 

BlueMSX supports that mode.

 

I don't know about TI99 emulators.

[+nanochess]

For Princess Quest and Mecha-8 as both use a lot of patterns, instead of updating the patterns (3 pattern tables and 3 color tables upto 12288 bytes!), I went the other way, I update only the tiles.

 

Patterns (already precalculated) are preloaded before the level starts.

 

And there is an intermediate table that gives the correspondence between tile number and real pattern for a given offset (0-7 pixels or less depending on your scroll rate)

 

In Z80 the code for copying to screen is very simple (the following code is repeated several times):

 

ld a,(de)    ; Read tile number pointed by DE
ld l,a       ; Index into translation table for pixel offset (reg.H preloaded before)
outi         ; Send data pointed by HL to VDP port (reg.C preloaded to VDP port)
inc e        ; Go for next tile (aligned to not use slower INC DE)

Edited May 17, 2013 by nanochess

[Asmusr]

For Princess Quest and Mecha-8 as both use a lot of patterns, instead of updating the patterns (3 pattern tables and 3 color tables upto 12288 bytes!), I went the other way, I update only the tiles.

 

Patterns (already precalculated) are preloaded before the level starts.

 

But I have 70 tile transitions in the demo x 8 scroll offsets = 560 characters. How would you preload all those?

[Tursi]

Interesting workaround, Youkie.. definitely makes me want to spend a little more time on this.

 

[+nanochess]

 

 

But I have 70 tile transitions in the demo x 8 scroll offsets = 560 characters. How would you preload all those?

Well, there are tricks.

 

The vertical scroll uses just too much characters (because the three patterns should be the same,) so you should check the speed you want to get and you can limit the scroll to 30 frames per second (at 60 fps you get blurred visuals in some TVs) and, by example, use only 4 scroll offsets (2 pixels per pass) plus careful tile revision to reduce combinations.

 

For horizontal scroll there are is an extra trick, each of the three sections (top, middle and bottom) can have independent tilesets , this way I managed to introduce some high-res graphics in Princess Quest.

[sometimes99er]

Also some nice tricks there, nanochess. Absolutely. Thanks.

 

http://www.youtube.com/watch?v=mPQ3PsrqpeU

 

http://www.youtube.com/watch?v=Vby9IohejKo

Edited May 19, 2013 by sometimes99er

[Tursi]

 

 

Do you still have the source code you used for your video available? I would like to test if changing the location of the sprite tables in VDP RAM makes a difference. I would also like to try it on my PAL console. Thanks.

 

I do, I'll post it when I get home on Monday.