Fast scrolling game howto, anyone?

[Chema]

This is awesome, I'm seeing the opportunity for an expanded Tracker to come of this, beyond the scrolling game engine .. well, *with* the scrolling game engine, maybe you could make a nice music editor as well ..

Thanks!. However I don't think this will end up as an expanded Tracker. You have to look to Twilighte's WAVE for that. This is much simpler, intended to be used within the game. Of course sources will be available, as usual.

I don't plan to create an editor. Coding music is quite easy from a music sheet. Maybe I can explain how I did this later, if anyone is interested.

In the video the player (which is using the 3 channels, btw) is running at 50Hz, which seems to be enough for my needs. However I have some concerns about how to integrate this within a game which uses a 50Hz IRQ to synchronize with the screen retrace. Even worse, as the game itself runs at 25 fps (cannot do it faster). The engine waits for an IRQ to happen (in fact it misses the first one and catches the 2nd, thus the 25fps) and then quickly dumps the screen to avoid tearing, so I'm afraid that playing sfx or music at that instant is not the right thing to do.

I could call the music player after the screen dump inside the code (not in the IRQ) but that would mean the player will run at 25Hz (with some small jitter that I think won't be noticeable). Another possibility would be having a 100Hz interrupt and calling the music player at even IRQs, while updating the retrace sync flag at odd IRQs.

Any other ideas? Maybe I should just test and see what happens.

[Xeron]

Why not have a 50hz IRQ, and service the display on even interrupts and music on odd? (so they both run at 25hz)

[Chema]

Why not have a 50hz IRQ, and service the display on even interrupts and music on odd? (so they both run at 25hz)

Sure. That is another possibility. Problem is if you slow down the rate of the player, the effects will suffer (not time enough for fast variations of volume/pitch). Anyway can't see another way to go, really.

[Dbug]

What's wrong in putting the player code in the IRQ? I do that all the time: That makes so many things easier!

[Chema]

What's wrong in putting the player code in the IRQ? I do that all the time: That makes so many things easier!

I'm using an IRQ at 50Hz to trigger a flag indicating when the vertical retrace is at the bottom of the screen. The main code does all the work and waits for that flag to be set. When this happens the screen is dumped, and the needed chars are redefined. I am already checking the keyboard in the ISR and I fear that also playing sfx could start making timings nasty.

I was even considering dealing with the keyboard as well as with the sound on even IRQs and setting that flag at odd ones....

[Dbug]

Well, you can split your replay routine in two parts:
- The 'compute the next batch of values to send to the PSG'
- The 'send values to the registers in the PSG'

The first one can run any time, can even bufferize a bunch of frames in advance if needed, while the second one is the one that needs to be played at 50hz to make the sound nice and steady.

It's very similar to the concept of preparing the bank of characters to redefine and the buffer to swap

[Chema]

... Which seems a good idea to me indeed!

It would be a matter of making sure you have the bank of registers ready when the next IRQ occurs, which should not be difficult, and could be made for instance after redrawing the screen...

Smart!

[Chema]

Okay, some advance on this. I think I should finish this game and dedícate it to Twilighte. That is the less I can do.

Still playing with procedural generation of the ship. This is quite more complex than I expected. The result is a bit dull, as not all the elements are included. Also need to tweak some thresholds and probabilities to generate more variying ships.

Anyway it is working.

I plan to have alternate sets for some tiles, so some ships may have different pieces and see if this may help with the "all ships looking the same" thing

If everything goes as expected, I can have a good number of levels, so difficulty may increase slowly during the game.

The generator is now around 2.2K.

Enjoy.

http://youtu.be/_beWPKEjemM

EDIT: I just noticed some "jumps" on the video when scrolling, which occur also when running in Oricutron. I tried this on a real Atmos and I think this did not happen. Will investigate more. Also I think it looks way better on the real machine, not sure if due to the aspect ratio or the CRT TV

[Dbug]

Nice

Have you tried to put some of the tiles in inverse video? Obviously that would not work well with having sprites overlaid on these, but if you have things like walls or buildings that are taller and cannot be passed over, you could use that to give a more colorful result

[kenneth]

Nice scrolling. I like the slow move of the stars. That makes a good effect.

Nice

Have you tried to put some of the tiles in inverse video? Obviously that would not work well with having sprites overlaid on these, but if you have things like walls or buildings that are taller and cannot be passed over, you could use that to give a more colorful result

Flashing attributes could be used too

[ibisum]

Love this, and love you Chema! Right on!

Notes, in case it helps motivate (let me know if not):

* Whats it like with bullets? You worked out how to put 100 bullets on-screen, or is that not a goal at this moment? (Bullets could be all the colour you need.. its space, after all. The only thing colourful in space is burning..)

* The ship-generation seems pretty good to my eyes, I'm not looking critically at it, but I agree with Dbug that a kind of "Zaxxon" element to the game-play, with impassable buildings/obstacles, is going to make the ship-generation a lot more sensible. If you can auto-generate, literally 100's of levels this way, with a very compact set of inputs, its going to be a beautiful, beautiful landscape to fly over, or into. Or .. under?

* Continuing with "colour is from burning things" aspect, maybe the ship features, designed with space for the attr-setting in the first place, can 'seamlessly' reflect the color of weapons in use, i.e. when a rocket explodes near the cyan-wall feature, the wall 'lights up' in refelection of the explosive colors.

* Bullets could be 'woven' into the ship features - so that the bullets land on areas of the ship, or if they land 'near' areas of the ship, where space has been reserved for colour attributes, the bullets themselves are in place to exploit the color attribute area, reserved for the purpose. I hope I'm explaining this.. well, if not, the point is that the ship attribute generation could include pre-positioned colour attribute effects, which the bullets can activate on explosion..

Anyway, just notes, free for the ignorin' .. either way, count me in as a definite groupie, putting this game on a real Oric one day (hopefully soon) is definitely on my list of afternoon-things-to-do-with-the-kids ..

[Chema]

Thanks for your comments

I have indeed in mind to add some color by inversing some tiles. Remember, though, that this is TEXT mode (the only way to do such a fast paralax scroll), so no nice AIC effects. In particular the "LEGO" bricks (as Dbug called them) are ship defences, and you should avoid them or be destroyed. As Dbug suggests, these can go in inverse easily.

Some elements of the ship will be "shootable", giving the player bonus, and I am evaluating the possibility of adding a "jump" action, so you can jump over the obstacles if needed. That should compensate for the speed.

I also had the idea of setting some elements you could fly "under", but not sure if I'll be able to include them. We will see...

It is impossible to have 100 bullets. Each bullet uses 1 tile, and we only have 96 per charset. Most of them will be used for the ship design, others for the masked drawing of sprites. But we should have room for a bunch of enemies and some shots, of course.

I think I should invest some effort now on the actual game mechanics. From shots, explosions, collisions,... to the enemy AI (I hope I can come out with something interesting) and then with something I have in mind to add a small twist towards a puzzle game mixed with the classical shoot'em up.

I take note of all your suggestions and advice. After all I don't have a clear idea about the details of the game, so any help or suggestion is really appreciated!

In addition I tested this on a real Oric. No jumps or pauses indeed. Everything Works smoothly, except for a strange effect which I cannot explain. Maybe some has an idea?

The game is synchronized with the vertical retrace and running at 25fps. In my CRT TV I see, when scrolling at top speed, some kind of "persistency" in the image, as if two frames were displayed simultaneously. Is that something inherent to the TV tech or must I look for some kind of bug here?

[Xeron]

Don't forget that Oricutron is emulating a 50Hz display, and your computer display is not 50Hz, so it will never be possible to make it completely smooth.

I *think* that if you put Oricutron into OpenGL mode, SDL will use vsync, so if you set your monitor to 50Hz somehow and used OpenGL, maybe you could get smooth scrolling in Oricutron (but I'm not 100% sure).

Of course, in OpenGL mode, you can have the correct aspect ratio as well.

[Chema]

Don't forget that Oricutron is emulating a 50Hz display, and your computer display is not 50Hz, so it will never be possible to make it completely smooth.

Thanks Xeron. I should have figured out that by myself. That must be the reason of the "jumps" and "pauses" when using Oricutron. Nothing grave, anyway.

I re-read my last post and noticed that probably the cut&paste demon created some havoc. In the last paragraphs the strange effect I am talking about is the strange "double-image" I get when running in a real Oric with a CRT TV. It is *nearly* as if you draw two images (one with a one-tile displacement due to the scroll) to the screen, so they mix together. I expected some persistency but it seems quite too much. I am not sure if I got used to the new tech monitors or what...

[Chema]

I've been thinking on all this, and would like to share these ideas with you, in order to see if anybody brings some light or ideas.

First of all I think the strange effect I see on the real machine might be caused due to the interlaced mode. Is the TV working in interlaced mode? If that is the case it is possible that I am updating the screen between the two interlaced frames, causing this double image effect.

I am updating the screen ever two interrupts, at 25hz, but that does not ensure that it is not updating between the two passes of the interlaced image.

Does that make sense? I guess that I could try to sync to avoid this, but need to think about it.

About the general idea of synchronizing with the vertical retrace, it does have some difficulties. You have to update the screen memory while it is not being sent to the tv. Usually you'd use the blank part of the signal. In the Oric, only 224 of the total 312 lines (half the vertical resolution of the tv) represent screen content, so we have:

20 ms per frame, 312 lines, approx 6.4 microseconds per line.
312-224=88 lines, 5.6 milliseconds or 5600 cycles.

Seems too little to do anything. Dumping the screen takes more than that. However, as the play area is smaller, just 160 lines, 40 are for the top panel and 24 for the three bottom lines where the radar is displayed, we can go up to 88+64=152 or more than 9700 cycles. That is better.

However there is another issue. I am redefining some characters in the charset to draw masked sprites. I cannot do this while the image is being drawn, so the drawing of sprites must also be included in the above calculation. And things get nasty. Drawing more than 5-6 sprites will quickly take more than 7000 cycles, so again no time.

I made yet another kludge and changes how the screen data is dumped, so full rows are drawn top to bottom trying to keep drawing ahead of the screen beam. It, surprisingly, worked, but timing is still too tight to keep more than 8-10 sprites without starting to experiment glitches. Not to mention that this timing avoids losing cycles in the drawing routines, for instance for dealing with inverse tiles.

There is an option for this, which is using different set of tiles for drawing sprites every other frame. That way the drawing can be done before, and only the dump will need to be kept in that timing.

But that cuts the possible simultaneous sprites to half. Not sure how mane tiles I will have left after finishing the ship, but even in the best, and improbable, case that I have 45, as each sprite takes two, and we need another two for this trick, we are back to the limit of 10-12 sprites at the same time. Frankly I doubt I will have so many tiles left.... Have I found a limitation I cannot fight against?

I know this is all a bit technical, but I am sure that those in the demoscene can provide some insights and ideas. Maybe I'm completely wrong!