Streets of Rage 2 with Blitz
3 Attachment(s)
http://eab.abime.net/attachment.php?...1&d=1472824811
Here is another small Blitz 2 tech demo, which shows a few Streets Of Rage 2 characters moving on screen. The ADF is in the attachment, and it should run even on 512K OCS, but if not, then give it more RAM. The demo is nothing special, just objects that move left and right, to test Blitter performance on BOBs of this size. Controls: W,A,S,D --- move Player Numbers 1 and 2 --- create and delete enemies. Again a dual playfield setup is used, with an 8 color foreground and 8 color background. BOBs are of size 40*70, and the test results on a standard OCS A500 are: 8 BOBs + Player run at 50fps. Which is pretty good I think...In the original Streets Of Rage 2 on MegaDrive, you usually encounter 4 or 5 enemies at a time. So this amount + two players on screen would be possible to achieve with Blitz 2, if 8 color dual playfield setup would be used for the game, and if the coding is smart. And 8 sprites could still be used for smaller objects, or maybe even combined to get one extra enemy to screen (which could have colors like green and bright yellow, that are missing from the 8 color BOB palette). --- Here are some more 8 color OCS versions of the Streets Of Rage sprites: http://eab.abime.net/attachment.php?...1&d=1472824844 As you can see 8 colors (or actually 7, because transparency counts as a color) is enough when the palette is well designed. Although surely one can see that it's less colors than in the MegaDrive version, but I think that this is the only way to get a game like this to run at 50fps. And of course the background can still have it's own set of 8 colors, and the palettes can be adjusted between levels, with the background having more freedom on color choices. Compare this to the 16 color Golden Axe, that was most likely coded with Assembler: 2 or 3 enemies on screen at the same time, and framerate starts to drop at 3 enemies. :) --- The demo also uses two "Queues" for screen buffering, which is similar to normal double buffering, but it's lot faster. This 2 Queue method can only be used with Dual Playfields. So I use "QBlits" and two "Queues" and two alternating Bitmaps...no BOB flickering and it's very fast. Old BOB drawings are erased on the first Bitmap while new BOBs are drawn to the second Bitmap, and then it switches these every frame. And we don't have to worry about damage to the background, because all drawing happens on the Front Playfield. So I would say that Streets of Rage 2 is definitely possible on the Amiga, and one could surely make it with Blitz Basic 2. :D And as usual, the source is included in the disk, you can freely use it in your own projects. :) |
Good job :great How about using Final Fight "remake" engine?
|
Quote:
So it too could be used, but I like to program everything on my own, so if I one day would seriously start converting Streets Of Rage, I would most likely code my own engine. :) |
if someone wants to remake black tiger top game horrible conversion
|
I think Satan was not bad but it's more mimic than conversion.
|
There is more to a game than blitting bobs. Once you add enemy and level logic, you must contend with the slower parts of Blitz.
|
Quote:
The Amiga is capable of making a better version of Black Tiger than the arcade game. If done right, it could be something like a combination of Risky Woods and Death Trap. :) --- --- And yes, blitter performance isn't the same as the whole game, but from my experience with the Megaman X Blitz project, most loop time is spent either blitting BOBs or Tiles, or repairing the background graphics after blitting something. But in 8 color dual playfield setup the BOB blitting is two times faster, and there is no background repair at all. And although in a scrolling street brawler game like this there most likely would also be a tile creation scrolling system, but I noticed that in Sega version the scroll always seems to stop at certain points, and then you fight many enemies, and the scroll doesn't continue until you have beaten the enemies. So all serious fighting with multiple enemies basically happens in static non-scrolling screens. So the only thing that could cause slowdown is the game code itself...but code can always be optimized, while the blitter speed will always be the same, no matter what we try. :) --- Can any of you Assembler coders out there estimate how fast compiled Blitz Basic 2 code is when compared with ASM code? Has anyone ever done any comparison tests or something? Everyone says that Blitz is slower, but exactly how much slower? And what about basic BOB blitting performance? If this same short example program here would be done with ASM, then how many BOBs could you blit, while keeping the frame rate at 50fps? |
I'm no assembler coder, but I have been forced to use assembler in my Blitz projects. Some of it could be due to my coding style, but switching to asm also forces you to think smarter about how you code.
|
Quote:
|
Quote:
sorry to thread hijack |
Quote:
|
You will need to code AI for the enemies, collision detection, a smart priority algorithm so stuff aren't drawn on top of each other wrongly (like the demo is doing now), and all of this will need cpu time, which may cause slowdown.
One question about how amiga draws things: is it possible to draw a sprite with the depth between two different BOBS on the same playfield? I was under the impression that you draw sprites either on top or behind a playfield, that there would be no way to draw a sprite "between" BOBS on the same playfield. If I am not wrong (and I really have no idea), then your idea of using sprites for an extra enemy won't work. Actually I believe you wouldn't be able to use sprites for anything but background or foreground scenery, or for a panel for lives/score etc on top of the gameplay area. |
Quote:
So my idea for using sprites for enemies or gameplay objects wouldn't actually work. But this would free the sprites for other cool things; the best use for them would be "extra scenery" in the foreground and background, such as the street lamps in the first level or the flashing neon lights. Luckily sprite height is unlimited, so they would work fine for this purpose. And even the rain effect at the boss fight of the first level could be done with sprites. Here's a gameplay video of the MegaDrive version: https://www.youtube.com/watch?v=UPcwha5fJz0 As you can see, the scroll stops at certain points on the level, and when I tried the game on an emulator, there is a slight about 100 milliseconds pause when the scroll continues after stopping...I think it creates or loads the next street section during this pause. So it could be that there is no tile creation at all, but each street section is a few screens long pre-made bitmap, and each level is split into multiple bitmaps like this. Or at least that could be the most smart way to do it on the Amiga, a 4 - 6 screens long bitmap is possible, especially because it's only 3 bitplanes, consuming less RAM. And in fact I think Golden Axe on the Amiga has similar scroll pauses, sometimes with loading breaks. Maybe I'll make a quick scrolling level with basic gameplay and AI in place, so that we'll get a better idea. Shouldn't take longer than a week. :great --- And about the question on Blitz speed vs Assembler speed: it would be cool if someone would make speed comparison tests on compiled AMOS code vs compiled Blitz 2 code vs compiled Assembler code, on basic tasks such as different math operations, variable handling, condition checking, loops and BOB blitting, with source codes available on each of three tests, so that everyone can evaluate the tests and verify the results on their own. Then we would have some facts on the table on where the slowness of AMOS and Blitz is mostly located, and how serious it is, from a game making perspective. :) |
WRT Bobs - one good thing about games of this type is that the bitmap Y-position for the bob also equates to the Z-position (into the screen), so a quick bubble-sort for viewable bobs will result in the paste order, ensuring that the bobs towards the 'front' of the play area are drawn last.
Sadly, you can only put sprites in front of, or behind, the bitmap for each bitmap. But I like your idea for other sprite usage, such as streetlamp and rain. Interested to see how this project pans out. |
Quote:
But other than that, it should be quite simple and semi-automatic; each frame a "drawing list" is constructed according to the feet Y, and the characters whose feet are higher on the screen are drawn first. |
The game does this slight pause on real hardware too. I had an original cartridge of this, and I finished this game like dozens of times on every difficulty level (including the secret "Mania" one).
Actually, playing on Mania you can really see the power of the Mega-Drive, because the screen may get *really* cluttered with baddies and from what I recall it never shows a hint of slowdown. But just to let you know, even arcade Final Fight does have a few slowdowns here and there. Most people will accept slowdowns if they aren't abound and for good reasons :) |
the slight pause is due to the decompression of the Art assets :)
Nothing to worry about :) |
Quote:
Can't you also adjust the bob handle in Blitz 2? I'm sure you can set it bottom/left. Means you can do away with the offset for character height. EDIT: Yes you can. A quick flick throough the manual throws up 'Handle Shape #,x,y' Of course, if you want to be really showy, then have the Y movements a bit bigger at the bottom of the play area, and give your perspective a bit of a 3D feel ;) |
Yes, the Handle Shape command is very useful in a game like this, it basically allows us to make those offset calcultions when shapes are loaded, instead of the actual game loop. :)
I now have an Y ordering system in place, which works 100% and takes about 15% of loop time. Currently 6 BOBs + the Player run at 50fps, with the appearance of the 7th BOB causing slowdown. But when we enter the "slowdown zone", I can add more BOBs without further slowdown, until about the 15th or 16th BOB, at which point the game enters the next "slowdown zone". And this is good, because the first slowdown zone is still playable, it runs about the same speed as Golden Axe with 3 nasties on screen. So it's looking OK so far, I'll now try to add some AI and collision detection, which most likely cost us one or two BOBs more, leaving 4 or 5 BOBs + Player at 50fps, which is the same as the MegaDrive version at "Normal" difficulty. :great |
Hi!
Someone suggested elsewhere in this forum that you can go for higher number of objects if you draw half the bobs in one frame and the rest of them the other frame. Well I tried to do that with your code and I think I got it working properly. Granted it's not that smooth but maybe you or somebody else could find a use for it or maybe even improve upon it. Personally I don't mind it that much and I would be interested to know how it fares on a real machine since I don't currently own one.:great Anyway here it is: Code:
WBStartup ; makes the program startable from icons and autoboot |
All times are GMT +2. The time now is 17:06. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.