31 January 2021, 00:02 | #81 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,411
|
Yeah, AGA attached sprites all use the odd palette. It's one of those "WHY!?" things.
|
31 January 2021, 00:02 | #82 |
Registered User
Join Date: Jul 2015
Location: Novi Sad, Serbia
Posts: 1,648
|
@Roondar
Thanks for clarification bro. I am not sure why people wants parallax that bad. Imho, it doesn't add that much visually (especially in 1vs 1 fighting game (I agree it adds much to the side scroller shooter games (or even platforms)), and I'd always prefer great gameplay, over the parallax. I mean, even in this (great) demo, he is starting with parallax in his test. To mee, ot looks like building a house from the roof. Why not starting the project with characters and all moves, and great gameplay (no slowdown), and then, if enough memorry left, you do parallax, and/or animated BG? |
31 January 2021, 00:03 | #83 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
I'm going to try it tomorrow. Edit - Thought about it and read some more, you are right so I guess each character would need to be 8 colours only which will probably make it look crap. Last edited by mcgeezer; 31 January 2021 at 00:11. |
|
31 January 2021, 00:04 | #84 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
|
31 January 2021, 00:09 | #85 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,775
|
well I suppose everyone wants to know if it was possible.
if the tile set didn't save much then maybe the snes character sheet could fit into memory complete. |
31 January 2021, 00:12 | #86 | |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,212
|
Quote:
Having said that, there's no reason why they can get a good conversion of the game in there too.. they have a whole playfield free for the characters |
|
31 January 2021, 00:13 | #87 | ||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,411
|
Quote:
Quote:
|
||
31 January 2021, 00:20 | #88 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Memory is the big problem (but you know this). |
|
31 January 2021, 00:36 | #89 |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,212
|
Yeah, I definitely think an "on the fly" decompression system would work.
When you trigger an animation on a character, you are going to require the first frame of the animation sequence right away to display. The first frame will need storing uncompressed. Then the next frame of animation, does that get displayed actually on the next update after that ? I seriously doubt it... even on the 3rd frame after that, would it switch to another frame of animation, i doubt that too.. anyway with that said, you then could run a CPU task in the background decompressing the next frames of the animation sequence before they are actually needed... animation sequence changes suddenly ? fine... halt the task, grab the first uncompressed frame of the new anim, and set the task off again for the new anim sequence... Decompressing could simply be constructing the next frames from 8x8 tiles (or 16x16 if that makes you more comfortable), to even perhaps a proper fast LZ decompress of the data |
31 January 2021, 00:40 | #90 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,411
|
That's a clever solution. But honestly, it also feels like a pain to implement and get it to work properly. One of those things that's easy to write down but maybe not so much to code
|
31 January 2021, 00:47 | #91 |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,212
|
|
31 January 2021, 01:15 | #92 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,411
|
Well, what I'm getting at is the different compression rates/speed of decompression you might get for each frame. It may end up being difficult to guarantee that all frames will be decompressed fast enough (though obviously you do have some time so it may end up being fine).
|
31 January 2021, 01:29 | #93 | ||
Ex nihilo nihil
Join Date: Oct 2017
Location: CH
Posts: 4,886
|
Quote:
There have always been people ready to upgrade their computer hardware. Otherwise no expansion card would have been sold, ever. Quote:
Last edited by malko; 31 January 2021 at 01:43. |
||
31 January 2021, 02:53 | #94 |
Registered User
Join Date: May 2020
Location: Toronto / Canada
Posts: 1
|
@mcgeezer: in your memory usage calculations, did you account for the sprites facing both directions?
@roondar: it would be rather easy to ensure that the decompression fits within a given time budget (with some affordance for unknown conditions such as interrupts), as for each animation frame this could be calculated in advance, and some frames could be pre-discarded based on this information. The arcade system uses tightly packed blocks of 16x16 pixels for sprites, and I recall seeing the layout of the animation sheets for ROM allocation didn't leave much wasted space, so in theory it is possible to calculate the space required to store EXACTLY all the animation frames for all characters and then double that (remembering that the Amiga does not have the ability to flip them horizontally)... Fightin' Spirit had quite a bit of clever memory management work to run on 1MB A500, and then on the A1200... Last edited by Frio; 31 January 2021 at 03:02. |
31 January 2021, 08:37 | #95 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Yes people will point to Team 17 games that needed extra fake fast to run but that is a different scenario. |
|
31 January 2021, 09:27 | #96 | |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 191
|
Quote:
Maybe using 32x16 instead of 16x16 so you can use 32 bit read/writes. With cpu you can read 4 plane words/longs into register, creating mask by ORing all together and flip if necessary all in one "step". As for the BOB blit: in theory you can blit both players with COPY and only the area where second player blit overlaps first player blit you need COOKIECUT blit. The second blit for such cases needs to be split up into smaller blits -> think Region functions of graphics.library. (Region = list of non overlapping rectangles to describe any possible shape. Used a lot in windowing systems). Actually the RESTOREing (clearing in case of blank background, or copy back from restore buffer if non-blank background) part of BOBs can in theory be almost completely "optimized" away for any kind of situation/number of objects, but computations/number of blit splits may be too much depending on how the objects move, how many of them and how often end up overlapping. If you have two screen buffers + an always clean restore buffer. Code:
foreach frame { /*update a region R_NEW describing the area where you are in the progress of blitting objects into during each bob blit */ R_NEW = new Region(); foreach bob blit { blitregion1 = blit rect INTERSECTING with R_NEW blitregion2 = blit rect MINUS blitregion1 blit blitregion1 using COOKIE CUT blit with background (C) = current (hidden) screenbuffer blit blitregion2 using COOKIE CUT blit with background (C) = restorebuffer add (OR) blit rect to region R_NEW. remove (CLEAR) blit rect from region R_OLD. } /* Restore blit only for those area where there were BOBs last time (frame), but not this time (frame). for each rect in R_OLD { COPY blit from restore buffer to screenbuffer } delete R_OLD R_OLD = R_NEW } |
|
31 January 2021, 09:47 | #97 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,475
|
This can work, add a pre-(de)pack stage, that can also be something from LZ(78) family, maybe better than a LZ(77/SS) because a 'global' dictionary is probably more effective in this scenario, and you have excellent space management.
It remains to be understood how much stress is this for the poor 020 and the bottleneck cause chip-ram |
31 January 2021, 11:14 | #98 | |
Registered User
Join Date: Mar 2020
Location: UK
Posts: 243
|
Quote:
You are right though - nobody would have paid extra on an expansion to play SF2 when you could get a SNES with two 6 button pads and the game for less than the memory expansion. |
|
31 January 2021, 11:18 | #99 | |
Registered User
Join Date: Nov 2010
Location: South Wales
Age: 47
Posts: 937
|
Quote:
|
|
31 January 2021, 11:18 | #100 |
Registered User
Join Date: Mar 2020
Location: UK
Posts: 243
|
And of course there is already a great playable version of Super SF2 on the Amiga, it just looks crap.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Street Fighter 2 | weirdreams | Retrogaming General Discussion | 4 | 20 June 2012 23:15 |
Super Street Fighter 2 | Retro1234 | project.Sprites | 94 | 12 December 2008 11:20 |
street fighter | stuntpup | project.WHDLoad | 5 | 30 August 2007 20:45 |
Street Fighter III | Muzkat | Retrogaming General Discussion | 11 | 14 August 2007 00:55 |
[Fixed] Street Fighter II | Amigaboy | HOL data problems | 5 | 30 December 2002 21:34 |
|
|