13 February 2021, 23:24 | #461 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,423
|
|
13 February 2021, 23:27 | #462 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,789
|
Sorry just edited by post ill just put my edit here in a min.
|
13 February 2021, 23:33 | #463 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,789
|
Ok Ok so its just basically the same as mcgeezer except they are using large Bobs for the characters and sprites for the water.
So all sprites are used up on water etc ok cool still looks very PC animation and very misleading. |
13 February 2021, 23:40 | #464 |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,212
|
Yes, they are using one playfield and hardware sprites to construct the backgrounds, leaving one playfield free for all foreground bobs (players and effects etc..)
To move the ship up and down, they only need to adjust the bitplane pointers |
13 February 2021, 23:44 | #465 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,789
|
Thanks, really what I was wanting to know is what part of the video is on Amiga rather than what parts of the video are possible or not possible I'm not questioning the theory but what part was Amiga.
maybe parts at 23ish and 26, thanks everyone for the confirmation. |
13 February 2021, 23:50 | #466 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,423
|
To be fair, I'm not entirely sure any of what is shown in the video is actually captured from an A1200, it looks very clean for a capture. But it could be WinUAE for the Amiga parts. I don't actually know. All I did was quote them, it's up to others to make of their statements what they will.
For the record, I don't think most of what they've shown is impossible. Whether or not the extreme BPLCON4 stuff at the end can all be done exactly as shown is an open question (though some form of what they suggest ought to be doable, if fiddly as hell to get into the Copperlist and design for every single level). Same with the memory requirements for characters with all moves rather than just them doing their idle animations as they haven't gone into how they want to deal with storing character GFX yet. But, I'm inclined to keep an open mind and see what they come up with next. Hopefully they can release an actual executable version at some point, better than just video I think. |
13 February 2021, 23:55 | #467 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,789
|
yeah winuae whatever just first time I saw it I just thought click bait a load of video clips etc but all cleared up up now thanks
|
14 February 2021, 00:23 | #468 | |||
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Let's also assume they can hold all player frames unpacked in ram (which they can't) as they are rectangles up to 128x128 in size, the blitter can't render that size rectangle as a straight copy and then the same size again in a cookie cut .... and THEN clear them again in one frame. So holding all the frames unpacked in ram... they run out of chip ram. Packing the frames in ram? Well then they have to unpack the frames into the correct position using the CPU...doubtful at 50FPS. They might be able to hold the first frame of each move in ram and unpack the rest but again I'm dubious about this with the ram requirements. Don't forget that each opposite frame needs to be mirrored and shifted on the fly too. (taking into account the trick Dan mentioned about holding the upper and lower sprite parts in different directions - most of the times the players will face each other which negates the need to do this, but I accept it is an efficiency) Let's say they do what I did and create 16x16 tiles of each sprite and rebuild them each frame, this is doable until it comes to the second player because the mask then needs to be included when mirroring the frame along with being shifted. Knowing what I know now they could look to hold mirrored copies of the tiles in chip ram and use the blitter purely for rendering with the barrel shifter, but then even this approach would need calculating and cookie cutting would be intensive. Quote:
Quote:
chip ram filling up the size you need and then fill it with what ever bitmap you want, no need to shift it, and the data in there is not affected by other things going on in the playfield so you can keep the data there for multiple frames at zero cost. Apologies if I waffled on. |
|||
14 February 2021, 00:47 | #469 |
pixels
Join Date: May 2014
Location: Australia
Age: 52
Posts: 476
|
Nice work on the tech demo mcgeezer
Was following this for a few weeks and couldn't resist a quick mockup. Cut up this scene into 8 pixel blocks (16 colour copper per split), kind of similar to Boss Machine technique. Reducing 109 colours was no small challenge and still needs alot of tweaking in the upper part. |
14 February 2021, 01:44 | #470 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,557
|
@invent
To keep the perspective effect those two elephants on the left gotta go from the background playfield, guess you are aware of that |
14 February 2021, 23:35 | #471 |
pixels
Join Date: May 2014
Location: Australia
Age: 52
Posts: 476
|
Hi @saimon69 yes true, (animated elephants each side) I grabbed the arcade background from here https://vgmaps.com/Atlas/Arcade/ probably could of sourced better image.
|
15 February 2021, 05:33 | #472 | |
Zone Friend
Join Date: Mar 2004
Location: Middle Earth
Age: 40
Posts: 2,127
|
Quote:
I never knew that there were windows on the right hand side. But damn that was an annoying level with those elephants making noises the whole time. |
|
15 February 2021, 11:58 | #473 | |
Ex nihilo nihil
Join Date: Oct 2017
Location: CH
Posts: 4,935
|
Quote:
|
|
17 February 2021, 17:41 | #474 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,646
|
I should do a video showing how i can finish the game using one move. Only Goro proves a bit of a problem.
|
17 February 2021, 18:52 | #475 |
Registered User
Join Date: Jul 2015
Location: Novi Sad, Serbia
Posts: 1,661
|
I was speaking about MK2 AI.
|
18 February 2021, 12:21 | #476 |
cheeky scoundrel
Join Date: Nov 2004
Location: Spijkenisse/Netherlands
Age: 42
Posts: 6,944
|
MK2 "AI" is a big cheater indeed on any platform; it's pretty much more A than I. I don't remember MK3/MK Trilogy being much better though. Push comes to shove these games were made for human-human fights, the AI was a nice bonus for practice purposes.
|
18 February 2021, 13:23 | #477 | |
Registered User
Join Date: Aug 2010
Location: Italy
Posts: 787
|
Quote:
Also, considering the color splits on horizontal basis, besides the complexity of it all, there's also the performance impact: to handle the scrolling, the CPU would have to update a large number of the Copper WAIT instructions each frame. |
|
18 February 2021, 13:32 | #478 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,423
|
Quote:
That said, I suppose a version of what they show ought to be possible with few issues. For example, having a single horizontal split between the boats should definitely be possible without too much issues. You can probably scale this up somewhat, but like I said I'm not completely convinced all of what they show for their ideas on horizontal Copper splits can be done even on a static screen. However, I'm more than happy to eat crow on this if they pull it off |
|
18 February 2021, 15:02 | #479 |
Registered User
Join Date: Aug 2010
Location: Italy
Posts: 787
|
Agreed.
Whether it's doable or not depends also on whether the game is supposed to run at 50 fps on a stock A1200. For example, this (from 21:34 in the video)... ... has 10 colors zones: given that it's 2 more than the hardware can offer, the Copper and/or the CPU have also to update the COLORxx registers dynamically. Moreover, there are 80*2 + 64*5 = 480 horizonal color splits that need to be adjusted each frame. And that's just for this single boat - and we know that the whole scenery is quite richer Asking the stock A1200 to handle all of this while rendering the big characters (possibly) flipping them in real time, handling the AI (I have no idea of how refined/demanding it is, though), etc. sounds a bit too much to me. On top of that, actually, even if with proper programming it's possible to have the Copper WAIT+MOVE couples end precisely where the horizontal color splits happen (provided that the color zones are at least 10 pixels wide), still that can't be done at odd boundaries, so I'd say that, regardless of the speed, it is not possible to achieve exactly what shown in the video. Just for clarity: I'm not saying that the base concepts are not valid, just that they've been a bit over-optimistic. Last edited by saimo; 18 February 2021 at 21:33. |
18 February 2021, 20:20 | #480 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,557
|
Still not a coder but i think there are many misconceptions on the blitter/copper system works; me too i thought in the past that was possible to achieve a simil-tile system using it thanks to the 8 pixel horizontal increment (not counting the parameters change time) and the OP of the video got same misconceptions as i did;
|
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 |
|
|