English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. Blitz Basic

 
 
Thread Tools
Old 03 August 2019, 01:21   #21
Shatterhand
Warhasneverbeensomuchfun

Shatterhand's Avatar
 
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 36
Posts: 3,430
I've never coded anything on AGA (For the obvious reason: I never owned an AGA machine), I don't know exactly how slow is the Blitter to blit 6, 7 or 8 bitplanes.

But... couldn't you use Dual Playfield, have 16 colors for Background, draw one character as a BOB with his own 16 colors and the other character as a HW Sprite with his own 16 colors too?

This way you should have enough sprites to draw even the wider frames, and not having to redraw background while blitting the BOB probably would give enough speed to run everything on one frame.

I dunno if using, say, 6 bitplanes to have at least 64 colors, so you can have 16 for the BOB fighter and 48 for the background would be fast enough to draw/redraw backgrounds and BOB each frame. But on Dual Playfield I believe it would be fast enough.
Shatterhand is offline  
Old 03 August 2019, 01:52   #22
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,364
AGA Blitter (if the screen is properly set up) gets roughly the same number of bobs in 6 bitplanes as the OCS one does in 4BPL. In the 'real world' the difference can be bigger because the CPU in the A1200 is much faster than the A500 so there are more cycles left for blitting. It can also do some of the Blitter's tasks in similar amounts of time, which frees the Blitter for other tasks.

Your idea has merit, but on AGA sprites and horizontally scrolling screens are tricky to combine in an efficient manner. If you can fix that, the DPL + Sprite technique should give you ample cycles to do two massive characters and any projectiles.
roondar is offline  
Old 03 August 2019, 15:13   #23
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 475
And of course, the character plotted on the bob playfield would not need masking... and with clever use of plotting extra blank data either side and above and below, could even clear itself when plotting the next frame
DanScott is offline  
Old 03 August 2019, 15:19   #24
Retro1234
Boo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 4,366
Master484 might disagree himself but I think what he's done already is the way to go we've had all the slow terrible ports using Bobs for the characters, using Sprites your guaranteed a fast game with big characters.

Last edited by lilalurl; 03 August 2019 at 17:20.
Retro1234 is offline  
Old 05 August 2019, 16:35   #25
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 409
Quote:
couldn't you use Dual Playfield, have 16 colors for Background, draw one character as a BOB with his own 16 colors and the other character as a HW Sprite with his own 16 colors too?
Yes, this is one possibility.

The only complication would be how to split the animation frames of each character so that they can be easily loaded either as BOBs or as 64 pix wide sprites.

For example I would normally split each BOB frame into smaller parts to save chip RAM; legs and heads would be cut from the main body and so on, so that the overall BOB size is smaller. And these BOB parts can be of any size. But for sprites every part would always need to be 64 pixels wide. So some extra planning would be needed. But I'm sure it can be done.

And because fireballs are needed too, I think that in this system the BOB players fireballs would be BOBs, and the sprite players fireballs would be sprites, which means 3 sprites for the character and 1 sprite for the fireball. But 3 sprites should still be enough to handle almost any animation frame.

And then there are the "throw moves" where characters need to be displayed in front or behind of each other at any time. So during these frames the sprite display setting would need to be changed every frame, to either front of both Playfieds, or between the two Playfields. Blitz can do this, although I haven't tested if it can be done in real time or was it a command that had to be given before the Display is created.

---

But yes, I think this could work, and it would be fast enough to run at 50 FPS.

Both characters would now have their own 16 color palettes, but on the other hand backgrounds would change from 32 colors + 2 parallax layers to 16 colors + no parallax.

Which way would look better, I don't know.

Quote:
I dunno if using, say, 6 bitplanes to have at least 64 colors, so you can have 16 for the BOB fighter and 48 for the background would be fast enough to draw/redraw backgrounds and BOB each frame.
In the other SF2 thread I tested AGA drawing power with 128 colors, using arcade size characters:
http://eab.abime.net/showpost.php?p=...0&postcount=79

And it could draw 1 character + 3 fireballs at 50 FPS.

So if only one character was a BOB and the other one a sprite, and in 64 colors instead of 128...I think it might actually run at 50 FPS, even when we add music and game logic.

And at 25 FPS the result was 2 characters + 6 fireballs...so a decent speed SF2 at high colors is definitely possible, if we only look at the "can the blitter handle it" aspect...but the real problem is of course the chip RAM usage of high color GFX.
Master484 is offline  
Old 06 August 2019, 15:27   #26
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,487
Are you coding this in assembler and are you using full 4 bitplane masks for the sprites?

I can't see any reason why this wouldn't get 50FPS on a stock A1200, Sprites for the panels, Dual Playfield for scrolling and background and a little algorithm to part blit the sprites to make up each player - maybe 4 blits max each from largest to small rectangles. Use a third back buffer too for restore speed.

Pretty straight forward unless I'm missing something??? You'd need a fair amount of chip ram but I can't see it being too much of an issue for only two players.

The problem with this is the boredom of creating the sprite rectangles efficiently.
mcgeezer is online now  
Old 06 August 2019, 18:52   #27
Shatterhand
Warhasneverbeensomuchfun

Shatterhand's Avatar
 
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 36
Posts: 3,430
Quote:
Originally Posted by mcgeezer View Post
Are you coding this in assembler and are you using full 4 bitplane masks for the sprites?

I can't see any reason why this wouldn't get 50FPS on a stock A1200, Sprites for the panels, Dual Playfield for scrolling and background and a little algorithm to part blit the sprites to make up each player - maybe 4 blits max each from largest to small rectangles. Use a third back buffer too for restore speed.

Pretty straight forward unless I'm missing something??? You'd need a fair amount of chip ram but I can't see it being too much of an issue for only two players.

The problem with this is the boredom of creating the sprite rectangles efficiently.
From what I got of all the discussion, the main problem is that using just sprites for characters you'll have just 16 color for all of them.

Also, I am nearly sure that using just characters, even on AGA (and I may be wrong since I know nothing about AGA sprites and stuff) a Dhalsim vs Dhalsim, both doing the low stretch punch would be troublesome to do as there wouldn't be enought sprites to draw

I mean... look at this. How wide does this get?

Shatterhand is offline  
Old 06 August 2019, 19:16   #28
Retro1234
Boo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 4,366
Sorry to butt in Master464....
All existing ports have used Bobs and have been too slow or too small

Dhalsim Arms or legs could simply be Bobs it would still be alot faster than anything that exists already.

I would just say the elephants trunks on that level would require extra blitting if they were included (as blocks so still possible but maybe include them but they only happen on 68030+)

It probably be possible to do the game with Bobs on a 68020 but just think of nice Sprites moving totally unimpeded.
Retro1234 is offline  
Old 06 August 2019, 19:29   #29
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 409
Quote:
Are you coding this in assembler and are you using full 4 bitplane masks for the sprites?

I can't see any reason why this wouldn't get 50FPS on a stock A1200, Sprites for the panels, Dual Playfield for scrolling and background and a little algorithm to part blit the sprites to make up each player - maybe 4 blits max each from largest to small rectangles. Use a third back buffer too for restore speed.
Everything has been coded in Blitz Basic. And as a Blitz coder, I'm not even sure what the bitplane masks mean. I just grab Shapes with a command called GetaShape, and then either Blit them, or turn them into sprites with GetaSprite, and then put them to screen.

But the demo that I posted to the first post of this thread already runs at stable 50 FPS, thanks to the 64 pixel wide AGA sprites for the characters.

And even if the players were BOBs, or a combination of BOBs and sprites like Shatterhand suggested, it should still run at 50 FPS. These SNES sprites are relatively small, and I'm sure that even the A500 could draw them at 50 FPS.

But if you meant the other demo that was posted to this other thread, that was a 128 color mode test, with 128 color BOBs, and it ran only at 25 FPS with two characters. And I think it used the best AGA fetch mode, and a third back buffer too, and the fastest Blitz drawing command (QBlit) but still only reached 25 FPS.

Quote:
From what I got of all the discussion, the main problem is that using just sprites for characters you'll have just 16 color for all of them.
Yes, that is the only problem. Everything else is perfect.

Although as demonstrated in the sprite sheet that I posted in the first post, I managed to convert the 200+ color SNES sprites to an unified 16 color palette with just some minimal quality loss. But of course some compromises had to be made, and so in some characters the clothing colors are "wrong", and I understand if it bothers people. But maybe the palette could be improved ? If someone thinks they can do a better palette conversion, then post it here, I would like to see it.

Quote:
a Dhalsim vs Dhalsim, both doing the low stretch punch would be troublesome to do as there wouldn't be enought sprites to draw
Yes, but there is a simple solution to that: we just won't allow the players to select the same character. I believe it was like this in some versions of the arcade too (World Warrior maybe).

Quote:
Dhalsim Arms or legs could simply be Bobs it would still be alot faster than anything that exists already.
Yes, in an emergency some characters could use BOBs to display some moves. But this would mean that those BOBs would need to use the Front Playfield background colors, which isn't so easy, since every level has a different palette.
Master484 is offline  
Old 06 August 2019, 19:35   #30
Retro1234
Boo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 4,366
Would you use Dual Playfield for every Level? Some levels have little or No(?) parallax.

Are there shared colours for every level?

Dhalsim could be Blue or any colour.
Retro1234 is offline  
Old 06 August 2019, 20:24   #31
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,487
Quote:
Originally Posted by Master484 View Post
Everything has been coded in Blitz Basic. And as a Blitz coder, I'm not even sure what the bitplane masks mean. I just grab Shapes with a command called GetaShape, and then either Blit them, or turn them into sprites with GetaSprite, and then put them to screen.

But the demo that I posted to the first post of this thread already runs at stable 50 FPS, thanks to the 64 pixel wide AGA sprites for the characters.

And even if the players were BOBs, or a combination of BOBs and sprites like Shatterhand suggested, it should still run at 50 FPS. These SNES sprites are relatively small, and I'm sure that even the A500 could draw them at 50 FPS.

But if you meant the other demo that was posted to this other thread, that was a 128 color mode test, with 128 color BOBs, and it ran only at 25 FPS with two characters. And I think it used the best AGA fetch mode, and a third back buffer too, and the fastest Blitz drawing command (QBlit) but still only reached 25 FPS.
OK I'm no Blitz Programmer but I can probably explain the concept quite easily, Blitz likely has this mode to work with.

So you have a sprite sheet with 4 bitplanes and 16 colours, it is 40 bytes wide (320px) and 200px in depth.

When blitting a sprite Blitz might be blitting each bitplane one after the other which is slow. With the expense of of memory we can create a masked copy of the sprite sheet - again with 4 bitplanes but each bitplane is a mask of the sprite sheet.

When it comes to cookie cutting with the blitter you can then blit an entire sprite in one blit operation instead of 4.... along with a third buffer this makes this much faster.

In the blitter the registers go A=source sprite, B=mask sprite, C=Third buffer D=Destination, the minterm for it is $fca and it's explained in the AHRM pretty well.

I'd have a look in the Blitz docs and see if this blitting mode is supported... it's probably why you couldn't get it to go at 50 frames.

Geezer
mcgeezer is online now  
Old 06 August 2019, 20:26   #32
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 409
Quote:
Would you use Dual Playfield for every Level? Some levels have little or No(?) parallax.
That's right, some levels have no parallax, or have so little that you can barely notice it.

And for those levels I would not use Dual Playfield, but instead 32 or 64 color mode. This too is made possible thanks to the players being sprites; the background graphics can be freely changed to anything at any time.

The number colors that can be used in a level depends on the amount of animations that the level has. So more animations = less colors. This is to keep it at 50 FPS, but also levels have to be designed so that all of them take roughly the same amount of Chip RAM. And some levels have no notable animations or parallax at all, like the Sagat stage and the car breaking scene...so these could theoretically be even 256 color levels (memory permitting).

Each level would be analysed to see how it works on the SNES version, and then I would try to figure out the best way to replicate it on the A1200. And if the Dual Playfield approach wouldn't work well, then I could simply have just one playfield, but with lots of colors, even more than what the SNES version has.

And in all cases I would try to make the levels look better than the SNES, of course. For example even in this demo, I added the islands to the horizon, and also added animation to the music band drummer, which is not present in the SNES version.

And this way, little by little, customising everything, an "Amiga perfect" conversion could be made.

Quote:
Are there shared colours for every level?
Not really. But theoretically I think every level has a set of browns, and these could be used for stuff like Dhalsims legs/arms if needed. And I think every level also has white and some bright colors like red and blue, and in an emergency these could be used for fireballs if sprite channels aren't available.
Master484 is offline  
Old 06 August 2019, 20:40   #33
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 409
Quote:
When blitting a sprite Blitz might be blitting each bitplane one after the other which is slow. With the expense of of memory we can create a masked copy of the sprite sheet - again with 4 bitplanes but each bitplane is a mask of the sprite sheet.
Ok, thanks for the explanation.

And yes, it could be that Blitz is doing its Blits in that slower way.

I remember that somewhere in this forum people have been discussing something like this, and how Blitz can be "fooled" into blitting faster, but the methods used to achieve this were quite complex if I remember right.
Master484 is offline  
Old 06 August 2019, 23:10   #34
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,364
Quote:
Originally Posted by DanScott View Post
And of course, the character plotted on the bob playfield would not need masking... and with clever use of plotting extra blank data either side and above and below, could even clear itself when plotting the next frame
Now don't be silly. That would never work

At any rate, you might also be able to reduce the cost of moving the bob by simply having a static bob and moving the playfield instead. That way, only changes in the actual image would need to be blit. Though, given the number of animation frames in the game, it'll probably only be a minor advantage at best.
Quote:
Originally Posted by Shatterhand View Post
Also, I am nearly sure that using just characters, even on AGA (and I may be wrong since I know nothing about AGA sprites and stuff) a Dhalsim vs Dhalsim, both doing the low stretch punch would be troublesome to do as there wouldn't be enought sprites to draw

I mean... look at this. How wide does this get?
As it turns out (unless my mouse-fu is weak) Dhalsim plus arm gets to about 248 pixels wide at it's widest. Which will just fit inside of 8 AGA sprites* for one character. You'd need to do the other one with bobs.

However, there's one saving grace: the arm of Dhalsim is a rather special case and not at all that many pixels high. You could blit it seperately as a very wide, but thin bob. Shouldn't really be a problem to be honest. It looks big, but it's not actually that many pixels.

*) AGA sprites can be 64 pixels wide (4x64=256 pixels).

Last edited by roondar; 06 August 2019 at 23:23.
roondar is offline  
Old 07 August 2019, 00:31   #35
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,487
Quote:
Originally Posted by roondar View Post
Now don't be silly. That would never work
Indeed, it only works for the first sprite... additional sprites need to be cookie cut unless they dont overlap.
mcgeezer is online now  
Old 07 August 2019, 01:24   #36
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,364
Quote:
Originally Posted by mcgeezer View Post
Indeed, it only works for the first sprite... additional sprites need to be cookie cut unless they dont overlap.
Well, in SF2 there's two big sprites. Doing one with this method and the other with hardware sprites (or plain cookie-cut) should be a big gain by itself.

Anyway, it'll work with more than one sprite. It does take a bit of care during design and/or additional coding to select which sprites to draw in what order to maximise the number that can be drawn like this (and which require cookie-cutting), but it's perfectly feasible to draw at least some of the sprites in this manner in quite a few games.

That said, it's not a technique that works for everything equally well. A game like Rygar where enemies and the player can go pretty much anywhere any time will obviously benefit less than a game where enemy movement is more structured.
roondar is offline  
Old 07 August 2019, 09:33   #37
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,048
I am with McGeezer on this.
Should be very doable on an 1200.
Steril707 is offline  
Old 07 August 2019, 11:02   #38
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 42
Posts: 8,198
Send a message via MSN to dlfrsilver
Quote:
Originally Posted by mcgeezer View Post
OK I'm no Blitz Programmer but I can probably explain the concept quite easily, Blitz likely has this mode to work with.

So you have a sprite sheet with 4 bitplanes and 16 colours, it is 40 bytes wide (320px) and 200px in depth.

When blitting a sprite Blitz might be blitting each bitplane one after the other which is slow. With the expense of of memory we can create a masked copy of the sprite sheet - again with 4 bitplanes but each bitplane is a mask of the sprite sheet.

When it comes to cookie cutting with the blitter you can then blit an entire sprite in one blit operation instead of 4.... along with a third buffer this makes this much faster.

In the blitter the registers go A=source sprite, B=mask sprite, C=Third buffer D=Destination, the minterm for it is $fca and it's explained in the AHRM pretty well.

I'd have a look in the Blitz docs and see if this blitting mode is supported... it's probably why you couldn't get it to go at 50 frames.

Geezer
On a game so much elaborated as SSF2, every trick in the book has to be used anyway, and for sure, with a 68030, this game can perfectly be done with good coding, and of course fast ram in good quantity.

I have watched again SSF2 video longplay, and it's just evident the programmer had to make cuts because the target was not the 1200, but this CD32 console junk. Where do you want to go with only 2mb of chip ram, and no dedicated chip for tile display ??? This was a big mistake. Gametek should have gone the 1200 + hard drive + 68030 + 16mb of fast ram right from the start.
dlfrsilver is online now  
Old 07 August 2019, 15:04   #39
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 409
Also about Dhalsim, the SNES version is a lot smaller than the arcade. Here is a 2x enlargened pic of the SNES version:



The biggest attack animation is only 140 pixels long. So with 2 sprites 128 pixels of it can be covered.

And if the frame is shortened with 12 pixels, then 2 sprites can handle it. And this is what I would do; all frames that don't "fit" would be shortened. But I think only Dhalsim and and maybe some Sagat frames need this.

Many frames that look long are actually quite short, such as Zangiefs jump kick that's just 104 pixels long. And many frames are in fact exactly 64 pixels; so many that I think the SNES version uses 64 pixel wide sprites too.

And even when shortening is needed, the hitboxes of the attacks can still be long, even if the images would be slightly shorter, so it won't affect gameplay in any way.

The only problem is when Dhalsim does the fireball and this long attack right after; now we need 3 sprites.

But it's easy to make a system where fireballs can be drawn as either sprites or BOBs, depending on case. This would cause some sudden color changes to the fireball, but it doesn't matter.

And also the shadows in the ground would be BOBs.
Attached Thumbnails
Click image for larger version

Name:	SNESDahlsim2.png
Views:	154
Size:	4.9 KB
ID:	64011  
Master484 is offline  
Old 07 August 2019, 15:09   #40
Retro1234
Boo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 4,366
Can all frames of 2 players be fitted in 2mb and in Reverse.

The Shadow could be added to the Frames as one bigger image.
Retro1234 is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
SNES mini alexh Retrogaming General Discussion 36 08 January 2018 17:13
sf2 with cd32 pad support (whdload?) turrican3 support.Games 10 03 September 2013 17:36
A600 dual kickstart, dual boot drive TreacleWench Hardware mods 41 18 May 2012 13:02
Best SNES Platformers? Fingerlickin_B Retrogaming General Discussion 39 02 February 2010 14:45
US Snes Games on UK Snes Steve Retrogaming General Discussion 13 17 December 2001 23:48

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 14:32.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.10216 seconds with 16 queries