32 color shmup demo

[Anakirob]

Originally Posted by Master484

Yesterday I just managed to install the Ultimate Blitz CD, and today I figured out how to add the extra commands to it such as LoadTrackerModule and LoadPTModule. The tracker commands didn't work at first, but then I realized they required an A1200 setup, and now they work fine.

However, there seems to be a problem with this latest version of the SmackMyBitchUp mod: It starts to play, but then gets stuck into an infinite loop, and just repeats positions 10,11 and 12 forever. It seems that it was meant to do a loop at this position, but it gets stuck and the song doesn't progress any further. This problem happened with both LoadTrackerModule, LoadPTModule, and also with Protracker 3.1.

I don't know what causes this. But all the other mods you have posted load and play fine in both Blitz and Protracker.

I'm guessing that ProTracker does not like doing an E6x command and an EEx command on the same row. But maybe it's simply a matter of the order in which the commands are handled by the replayer and would work if the 3&4th channels were switched, it could be worth a try.

I used MilkyTracker to put these modules together, and while that program does have some ProTracker compatibility it is primarily a FastTracker clone and would behave like FT rather than PT. I may just have to forget about using loops to optimise this track and make it use two patterns instead of one. I'm about to go to bed right now, but this should only take me a few minutes and I'll get the bugfixed version to you tomorrow.

Although I am curious as to how OctaMED handles this file. Does OctaMED play it correctly? Rows 10-12 should play a total of four times and then move onto the next loop.

If I was not extremely busy with another project right now I might attempt my own custom music sequence format, as this track does not really require any of the features of a tracker apart from the actual sequence itself. And even that only really needs one channels worth of information. The sample can be made to play on both channels 1&2 with a single Blitz command. Before optimisation all the samples were the same length and would be triggered at regular intervals so it should be quite easy to know when to trigger them in the code.

[Master484]

Although I am curious as to how OctaMED handles this file. Does OctaMED play it correctly? Rows 10-12 should play a total of four times and then move onto the next loop.

Octamed didn't get stuck and played it normally.

Although with Octamed all these mods have one other small problem: After loading them, the speed setting is always wrong at first. For example in this latest mod, the speed sets itself to 033/08. And I then had to manually move it to the correct setting, which seemed to be 033/16. But other than that they seem to play fine.

[Anakirob]

Originally Posted by Master484

Octamed didn't get stuck and played it normally.

Although with Octamed all these mods have one other small problem: After loading them, the speed setting is always wrong at first. For example in this latest mod, the speed sets itself to 033/08. And I then had to manually move it to the correct setting, which seemed to be 033/16. But other than that they seem to play fine.

I had a feeling OctaMED would work, it's my tracker of choice when using a real Amiga. I have had some problems with the patternloop command before when saving my work as MOD rather than MMD.

Although the Speed setting is a little puzzling. Whenever I load a MOD into OctaMED 5 (and above) it switches to BPM instead of SPD. I could never make any sense of MED's SPD setting and always used BPM anyway.

The correct tempo values should be 136 BPM and 24 Vertical Blanks, but I'm guessing that 33/16 is the same thing.

Anyway, you should find the bug fixed module in your gmail inbox. But if it's not there then maybe check the spam folder. Files with attachments from people I have not corresponded with before often end up in my gmail spam folder.

[Master484]

Anyway, you should find the bug fixed module in your gmail inbox.

Ok I got it, this version works fine.

[s2325]

[ Show youtube player ]

[Anakirob]

Is that running on an A500? It certainly moves a lot smoother on my hardware, on both an 020 A1200 and even on my laptop running FS-UAE which chugs a bit when I'm multitasking a few things.

[s2325]

You may try to ask in comments.

[Master484]

It's just the Youtube video frame rate that causes a lot of extra frame skips in the video. I guess this happens when a low frame rate game is recorded at a low frame rate; game runs at 17 FPS, but I think the recording software didn't record every frame, and so it seems slower and more jumpy than it really is.

The game speed is locked to 17 FPS on both A500 and A1200, and it's as fast on both machines, the only difference is that A1200 can draw a lot more before slowing down to 14 FPS.

[Master484]

I finally managed to get AGA dual playfields working in Blitz, and made a new demo version.

The new ADF has been added to the attachments of the first post of this thread.

And as always the source code is included in the disk, you can freely use it in your own Blitz projects.

---

So now the demo is AGA only, and uses a 16+16 color AGA Dual Playfield screen at size 288*256.

Controls remain the same, with one addition: press "L" to fire that player mega laser.

And speed is still great, I counted about 50 bullets at 25 FPS on a standard A1200 with no fast mem. At the bottom of the screen there is a speed and object counter, "VPOS" is the position of the display beam after all drawing and game logic has been done, and the number after the "F" letter tells the frame number. Slowdown starts if frame number reaches 3 or more.

And I have now abandoned the "Xenon 2" technique and switched to "Battle Squadron" mode, so now we have a system like this:

1.
Only the Back Playfield (city background) scrolls (hardware scrolling), and this is done from the VBlank interrupt, so the scrolling stays at 50 FPS all times.

2.
Sprites and music are also still done from the interrupt and are always 50 FPS.

3.
All BOBs update at 25 FPS and are drawn to the Front Playfield, which is totally independent from the Back Playfield, which allows us to use fast QBlits without the need of a third "Unqueue source bitmap".

4.
And also because everything is now basically drawn into a clean background, objects can be drawn in lower bitplane amounts without visual side effects happening on the background graphics. So explosions and bullets are now drawn in 8 color mode, and player shots in 4 color mode. Although you can still see side effects when for example bullets are drawn on top of enemies, but this isnt serious, and even looks cool; for example explosions sometimes look like they have a transparency effect.

5.
There is no new tile creation, except when 3 screens have been scrolled; at this point there is a small pause and a new 3 screen background section is created with some 200+ Block operations, which causes a small pause, but you can hardly notice it. And in the actual game I think 6 screen sections will be used, and levels will be designed so that the new section creation always happens at a "chill out area" and not in the middle of battle.

---

And notice the long player laser ( that you can fire by pressing "L" ), it is actually a very long sprite of size 32*256. Doing a vertical blit like this with a BOB would be mega slow, but when made with a sprite it doesn't affect performance at all.

Also notice how one of the ships disappear when the laser is fired; it uses the same channels as the second player ship, so that's why this happens.

Right now, Players ship uses sprite channels 0 and 1, laser uses channels 2 and 3, and in addition to these one more channel remains free : channel 4, which right now displays a 4 color player sprite.

And the laser could of course be 4 colors instead of 16 colors, this would free one channel. And because this is AGA, sprites could be made 64 pixels wide instead of the current 32 pixels, and this wouldnt affect the available channel amount. 64 pixel wide sprites would of course be great for boss enemies and all sorts of mega effects, so maybe I'll experiment with them.

[Retro1234]

Nice

[Havie]

Looking better and better but why are you not blitting a couple of tiles a frame rather than loads at one? There would be no pause at all using this method.

[Anakirob]

The beam laser is a welcome addition, but pressing a key to activate it is a bit awkward.

One game I have recently been playing uses holding fire to shoot the primary weapon and charge the beam. and releasing fire fires the beam.

Or alternatively being able to use the second fire button to fire the beam would be a nice thing to do.

[Master484]

Looking better and better but why are you not blitting a couple of tiles a frame rather than loads at one? There would be no pause at all using this method.

Because blitting all the tiles at once is easier and a more clear way to do it.

And also this is a speed optimization; no real time tile blitting at all means a few more bullets on screen, which isn't much, but everything counts.

Although in the future I may make a system where at least some tiles of the next map section will be blitted during the "low stress" periods; and this should reduce the "stop time" quite a lot.

Or alternatively being able to use the second fire button to fire the beam would be a nice thing to do.

Yes, the second fire button would be much better, but for this demo I just chose "L" for Laser; and more keys will likely come later, such as "B" for bomb or number keys for power up levels...these keys are just for testing purposes. In the finished version gamepads and two-button joys would of course be supported.

[Anakirob]

Originally Posted by Master484

I finally managed to get AGA dual playfields working in Blitz, and made a new demo version.

...

So now the demo is AGA only, and uses a 16+16 color AGA Dual Playfield screen at size 288*256.

Might I recommend once again that you look into using the BitplanesBitmap command to assign bitmap objects to the individual bitplanes and set up your dual-playfield manually.

This could ultimately give you a lot more freedom with what your engine could do. For example with a bit of clever level design you could mix the standard 4-bit+4-bit display format with a 256 colour screen filling boss. Or you could have a 2-bit background playfield for a "space" level which would allow you to use 6-bitplanes in the foreground for that level.

So you could have your existing 16 colour background 16 colour foreground for one level but you would not be forced to use it all the time and could even change foreground and background playfield bit-depth on the fly.

And those are just a couple of the tricks you can do with this method, palette fading and transparency is another trick you would be able to do, and the list goes on.

It is a little more work, there will be a lot more lines of code. But ultimately it does not use much more overhead to Block each individual bitplane for a total of 4 Block's than to Block all four bitplanes at once, and if you were to replace the code that Block's and Blockscroll's the background playfield with custom 68K routines which are fixed to the display specifications then there's potentially quite a bit of optimisations to be made.

This would obviously require you to do quite a bit of experimenting with a new command, and I certainly don't expect this to be easy to implement, but it does work, I have used this method more than once. Even an experienced 68K coder I was working with on one demo project found this to be a versitile way of doing things. .

I don't imagine this being a feature of your engine any time soon, but I would definitely recommend looking into the BitplanesBitmap command if you are focussing on developing fancy graphics engines. It gives you so much more freedom and power over the Bitmap object.

[Toni Galvez]

Originally Posted by Master484

Octamed didn't get stuck and played it normally.

Although with Octamed all these mods have one other small problem: After loading them, the speed setting is always wrong at first. For example in this latest mod, the speed sets itself to 033/08. And I then had to manually move it to the correct setting, which seemed to be 033/16. But other than that they seem to play fine.

Hello, I like recomend you, to use 3 channel music (if you mix the kick and bass samples you can have drums and bass in one channel, we are doing like that) and 1 channel for sound FX.

It is terrible a game without music+FX, please consider that.

If I can choose, I choose 50fps player ship, 25fps scroll and enemies.

Thanks for investigate for a nice new game.

[carrion]

@Master484
It's really cool example of using BB. I learn a lot from it. Thanks

I work on my platform engine and still struggle with some problems.
here's example of what it looks like now.
http://retronavigator.com/post/16259...latformer-game

1. when I start adding bobs I get the flickering when they move.
how to avoid it? you add a lot of bobs and don't have these flickering which probably is caused by slow bitting
2. how do you control the 25 fps limit when putting bobs?

TIA

[idrougge]

Bltting and removal of bobs must be placed in the correct place around the VWait in your game loop. If this doesn't cure flickering altogether, you must go for double buffering. Blit all your bobs in an offscreen bitmap, swap with another bitmap around on VWait and do your work on the other one. Repeat.

[carrion]

@idrougge
what you mean by "correct" place? I always place VWait on top of mainloop.

in my current approach to blitting (BBlit) double buffering will be difficult to implement (IMO)
I would need to clear all quite big bitmap, repaint the tiles and the bbl it new bob.
change the buffer and repeat, repainting the tiles.
maybe repainting all is not necessary but some background storing and repainting must be done, which will slow down the process.

I know I could use qblit and dual playfield but for the tests I'm doing I need 32 colors.

btw: is double buffering used in this shmup engine ?

[idrougge]

Double buffering and BBlit shouldn't be any problem. You don't clear any bitmap. Just use one buffer per bitmap. But otherwise, you can use QBlit (which doesn't need dual playfield at all) with a triple buffer.

[carrion]

I don't want to do an offtopic but I'd love to read more about the ideas you are talking about.
As far as I understand double buffering I have to:
0. set screen1
1. draw tiles
2. blit a bob
3. change screen to screen2
4. draw tiles
5. blit bob
6. goto 0

the triple buffering is even bigger mystery to me.
I think I start new thread when do a YT movie with latest version of my platformer because this topic starts to be interesting i guess not only to me.