Robocop AGA

[rothers]

Originally Posted by S0ulA55a551n

How do you have an engine without graphics? What is that engine doing ?

I mean you can have a great engine that can quickly move things around calculate physics etc etc, but if the graphics are then mode O amtrad cpc

You're not a coder, are you?

It's perfectly reasonable to say an engine is good and the graphics are bad in a game. Happens a lot.

[S0ulA55a551n]

Originally Posted by rothers

You're not a coder, are you?

It's perfectly reasonable to say an engine is good and the graphics are bad in a game. Happens a lot.

That would be a bad assumption, but I am not paid to write games to be fair.

You cant really separate the two when comparing games, as so much of the systems resources are taken up byt the displaying of the graphics.

Hence Robocop in the arcades, and any port that is similar to it is more advanced than the garish mess that is robocop 2, in my opinion

But that's all it is

[roondar]

I don't really agree with that. The capabilities of the engine are completely separate from the capabilities of the artist using the engine. You could remake the Arcade version of Robocop with terrible GFX style and this would not impact the quality of the engine at all. Likewise, you could improve the GFX style of Robocop II without actually improving the engine.

[malko]

^ and when everything is put together in an excellent way some can achieve pearls like Dread, KFM, metro siege, reshoot, inviyya, etc., etc. ....
Maybe let's keep this thread for the OP to speak about the progress he is making on his AGA conversion of Robocop

[S0ulA55a551n]

Originally Posted by roondar

I don't really agree with that. The capabilities of the engine are completely separate from the capabilities of the artist using the engine. You could remake the Arcade version of Robocop with terrible GFX style and this would not impact the quality of the engine at all. Likewise, you could improve the GFX style of Robocop II without actually improving the engine.

Last OT, the artist is restricted by either the capabilities of the engine ( don't see how the game engine is separate in this case) , or the resources left to the system after you take into account everything else.

If the "engine" is doing wonderous things, butt hat only leave enough ram, cpu resources etc to have a monochrome game .....

In all real respects the "engine" and the graphical output are one in the same thing

[roondar]

Originally Posted by S0ulA55a551n

In all real respects the "engine" and the graphical output are one in the same thing

This is just not true, except in the most extreme of cases. And this is very clearly not one of those cases.

As an example, in this particular case, the GFX style for Robocop 2 might be problematic, but the actual GFX tech for Robocop 2 (i.e. a 16 colour screen with fairly big and animated objects on it) could be used to create a game that is very different in look (for instance, without the the garish tones) without needing any extra RAM or CPU/Blitter/Sprite power to do this.

But indeed, let's drop the OT.

[jotd]

couldn't we run some games through the WinUAE DMA debugger to see if they're using the full bandwidth and optimizing DMA/CPU or not?

Would need an interesting separate thread

[Tigerskunk]

Originally Posted by DanielAllsopp

Update #1

So that was a quick update! I've picked up my code again recently and implemented the dreaded blitter restore routine, which wasn't as bad as I thought it would be.

It seems to work well.

I also updated the scrolling routine and fixed a few bugs in there relating to Robocop's position when he reaches the end of the level. All simple stuff really, but it needed doing.

The video here is pretty much the same as the last one, obviously with the restore routine implemented, Robocop now doesn't leave a trail behind him!

Ahhh... simple things

[ Show youtube player ]

This looks amazing, mate..
Glad you took the plunge, and dived into 68K asm..

Hope you keep on. That's usually the hardest part.




(ah, one advice: check out early how much blit time you have left with your bitplane and sprite setup, and if it's enough to get all needed objects unto the screen. Changing this later on is a pain in the ass)

[DanielAllsopp]

Update #2

It seems I've gotten right back into my 68k coding learning zone as I've been tinkering with the engine over the last couple of nights. It has taken me a while to pick up some relative speed but it's coming back and it's a nice distraction from Swift!

So, in this update I've added the ability to switch between different sprites at different locations in the game.

For example, in the first level the background city in the middle of the level is created using four 64 pixel wide sprites, equalling 256 pixels, but because the screen is 288 pixels wide (the arcade is 256 pixels wide) they need to be automatically repeated across the whole screen using the SSCAN2 feature of the chipset.

Realistically the bosses at the end of the level will also need to use the sprite hardware as they're so big; 128x110 pixels for ED-209 in this level and that would kill a lot of raster time if it were implemented as a blitter object.

At the end of the level the engine will now automatically switch from using SSCAN2 and the city sprite data to using standard 64 pixel attached sprites for ED-209, totalling 4 hardware sprites. A nice benefit here leaves me with 4 spare hardware sprites to play with which I'm sure I can utilise for something nice!

I did come across one problem at this point, relating to the 288 pixel wide screen this Amiga version is utilising: when ED-209 appears on the screen in this resolution, there is a 32 pixel wide column on the left of the screen which still shows some of the city scape!



Switching the sprites off there would look a little bit strange, as the city would just disappear! A bit of creative fiddling with the map though, and we've got a slightly extended building utilising some existing tiles and no one but the eagle-eyed would know the difference... until now!



Here it is in action:

[ Show youtube player ]

Shout outs and big thanks for help during this little phase belong to:
- paraj: that damn copper!
- saimon69: music and sound effects. Awesome work!

[stevelord]

This looks amazing, you're doing an incredible job here!

[jotd]

this "enlarge building trick" is typically something that you wouldn't have done in an original Amiga game (because you would have created the level like that at first), and a compromise that saves you with the final HUGE boss.

Illustrates clearly the complexity of porting a game from a completely different hardware.

I love this.

[roondar]

I love this, clever trick with the building. Really looking forward to see more

[Konrad]

I'm very impressed. I really hope this project gets finished.

[redblade]

Excellent work DanielAllSop, now the youtube videos of long plays and comparison videos will have to remake and upload their videos .

Is it possible to get the .mod ??

[malko]

It's only the beginning and already : Whaou !
Keep the excellent work going.

[lmimmfn]

Fantastic work man, one of my fav arcades and this is looking like it can clearly match the arcade, keep up the great work!

The extra tiles are great but just curious, couldnt you just do 1 blit for that or are you using sprite colours not available in the playfield?
Its completely minor, im just curious if this edge case could be done, as theres only ~1 tike overlap between ed209 and the background in terms if ed209 height.

Either way, great work!

[DanielAllsopp]

Thanks for the kind words everyone, it keeps the old motivation up!

Originally Posted by lmimmfn

The extra tiles are great but just curious, couldnt you just do 1 blit for that or are you using sprite colours not available in the playfield?
Its completely minor, im just curious if this edge case could be done, as theres only ~1 tike overlap between ed209 and the background in terms if ed209 height.

Not sure I 100% understand your question, but I'll try and reply best I can.

I'm using 16x16 tiles, and the gap is 32 pixels so it would be blitting two columns to replicate the city so it can stay on-screen. Those city tiles aren't actually stored as part of the tile set either, and it isn't in the arcade game anyway.

The 16 colour sprite palette is changed between the city and ED-209, and it's completely independent of the background colours. It's single playfield, so for the city the sprites are pushed behind the bitplanes and switched to be in-front when ED-209 appears. Using a sprite in this case is imperative as it's basically "free". In fact, I get a little bit of time back when I switch the city off and ED-209 on.

If I've completely missed the mark with my response, let me know and I'll try and fix it for you

[vulture]

Just saw this, that's pretty awesome!

[agermose]

Goodie, one of my favourite arcade games. This is looking great already. Good luck with the project.

[New Sky]

Hello,

Great ! I was thinking about an Arcade version on Amiga not long ago !

Good luck for the future !