Discussion: Rygar AGA Edition

[Retro-Nerd]

Looks like they are emulated.

https://en.wikipedia.org/wiki/Arcade_Archives

...Parasol Stars

Now i got you. It is a PC-Engine original, not an arcade game.

[jotd]

You got me on both points.

Why I was saying that? because I witnessed DS ports and the screen layout was slightly different (DS vertical resolution is 200 pixels, less that most of portrait mode arcade games resolution at the time). So for instance pacman credit indicator is not at the original location.

Now I'm wondering: did they rewrite emulators or just copied MAME source code, which would clearly be a case of GPL license violation Hard to tell without disassembling and comparing code structures...

So rewriting the game natively avoids the use of an emulator and avoids a possible legal issue ... with their own product

[dlfrsilver]

Originally Posted by jotd

doesn't it annoy you that the game is recoded again and again? I'm 100% sure that emulation isn't used in those compilations (screen format, adaptations). Games are rewritten in whatever language is suitable, from original sources (if they kept them, which is likely). I'm sure it takes forever for them too, since they have the same issues as Amiga port has (except for the limited resources maybe)

I mean: the current sources are probably in C and we have to do the work over and over ... Well I don't mind that but sometimes I'd like a peek at the source (specially when I remade the bitmap bros games...)

Well, my original dream was: all arcade games that can be ported 1:1 or close should exist on the amiga (a bit like Atari did with Super Sprint, ... or the excellent Pang, Paperboy, Parasol Stars, Rainbow Islands and ... Bomb Jack). One more legend game like this, yeah!!!

The fact it requires a A1200 isn't a big deal. It's difficult enough to code on the amiga, let's have AGA & 2MB chip available at least...

Most of the coin-op games were coded in ASM, either z80 or 68000. Only a few of them were coded in C.

And never forget that back in the day, when japanese coders had to code, they prefered ASM over C in every cases.

the C part is only the linker/linking file.

[jotd]

I mean: if they are to recode the game today, they'll choose C or C++, and yes, they cannot re-use the original code since it was ASM.

I heard Marble Madness was written in C, though maybe that's why the port was so faithful.

[nogginthenog]

Originally Posted by dlfrsilver

Most of the coin-op games were coded in ASM, either z80 or 68000.

6809 was popular in the early days too.

[dlfrsilver]

Originally Posted by jotd

I mean: if they are to recode the game today, they'll choose C or C++, and yes, they cannot re-use the original code since it was ASM.

I heard Marble Madness was written in C, though maybe that's why the port was so faithful.

They would encapsulate the rom files in a C program, exactly how mame would do it.

[E-Penguin]

Originally Posted by mcgeezer

All i have at the moment is a contact to send a proposal to. Taking in to consideration what most people recommend i’ll hold off sending anything and just continue building.

It's always easier to seek forgiveness than permission!

[jotd]

encapsulating the rom files in a C program doesn't convert the program to C ! you have to emulate the CPU, the sound, the gfx. MAME doesn't encapsulate ROM files, it loads them as data, then uses generic/specific drivers, crafted year after year since 1995 to make the game work as faithfully as possible. I doubt that some developper, even good, can create a good arcade emulator in a few months, out of nowhere.

[mcgeezer]

I completed the collision bitmap tonight so that it scrolls left and right with the joystick. It's bringing in collision tiles every 16 pixels in the left and right borders depending on which way you move.

Additionally, I set the blit modulo to 8 Y axis pixels as opposed to 16 because I anticipate that the little Rhino sprite needs to know when it has hit a wall, 16 pixels height would be tool large for this and I wouldn't have been able to have it collide with an obstacle.

[ Show youtube player ]

PS. And if you're wondering.... Leo is my 3 year old son

[E-Penguin]

Nice

A technical question (if you don't mind giving away your coding secrets!) - how are you using the collision bitmap to detect collisions? When blitting the foreground/sprites?

[mcgeezer]

Originally Posted by E-Penguin

Nice

A technical question (if you don't mind giving away your coding secrets!) - how are you using the collision bitmap to detect collisions? When blitting the foreground/sprites?

Not really a secret. I just use the blitter Zero flag.

I’ll probably demonstrate it in the coming week.

[dlfrsilver]

Originally Posted by jotd

encapsulating the rom files in a C program doesn't convert the program to C ! you have to emulate the CPU, the sound, the gfx. MAME doesn't encapsulate ROM files, it loads them as data, then uses generic/specific drivers, crafted year after year since 1995 to make the game work as faithfully as possible. I doubt that some developper, even good, can create a good arcade emulator in a few months, out of nowhere.

Some companies still have the access to the dev documents, and also the original chip programming book.

It does not convert the program in C, but it allows to run it on a recent hardware. Most recent arcade games are using an emulator running on the target hardware. They don't pass the whole thing in C

[S0ulA55a551n]

Originally Posted by mcgeezer

The sprites are ordered on the basis of their type . i.e collectibles/enemies/players/explosions etc.

So for example you might have 100 sprites, 1-20 might be player animations, 21-50 might be collectibles, 51-70 enemies and 71-100 might just be for visual show... like explosions, enemy deaths or background animations like water falls.

So for sprites that don't interact with the player (like explosions) you don't want to generate any collision masks, so in this example the easiest way to do it is state any sprite drawn above 70 does not draw a collision mask and therefore won't affect the player if visually it collides during game play.

If it doesn't make sense I'll try and explain it a bit more later down the line with examples.

I guess I think of things differently and would not be doing collisions detection based on anything on screen, but by knowing where everything was and where it would be and working things out from there, if that makes any sort of sense

I guess on a poorly Amiga this might have a heavy overhead ?

[mcgeezer]

Originally Posted by S0ulA55a551n

I guess I think of things differently and would not be doing collisions detection based on anything on screen, but by knowing where everything was and where it would be and working things out from there, if that makes any sort of sense

As you probably know there's multiple ways of doing collision detection each with pros and cons, it generally boils down to accuracy vs efficiency.

Originally Posted by S0ulA55a551n

I guess on a poorly Amiga this might have a heavy overhead ?

Yeah this is true, but I try to set out what I need first and work back from there. For example looking at what the arcade pushes at any one time on screen.

[kamelito]

I knew I would find another place for this article on collisions
http://higherorderfun.com/blog/2012/...d-platformers/

[idrougge]

Originally Posted by jotd

I doubt that some developper, even good, can create a good arcade emulator in a few months, out of nowhere.

I think it's quite possible. You have to support only one single game, not an entire platform as is the case for UAE.

[mcgeezer]

For info at this point I moved all the code base across to using VASM/Notepad++.

You know it's time to do this when you spend most of your time looking for the lines you were editing in Devpac as opposed to actually coding.

Crap job, but must be done.

To help others I'll make a short video on how to set this up for others. Will be tomorrow though.

[jotd]

Wise decision. Once you removed the incompatible stuff from vasm & created a makefile, it runs fine. I added a hotkey to notepad++ to call the make command. Not so bad.

Personally, I consider the AmigaOS as an embedded device now: it's cool to create games for vanilla A500/A1200 configs, but don't try to develop on it in 2018 (even on a A1200/060/64MB/RTG like I used to have), it's too frustrating.

[mcgeezer]

Ugghhh... the trials and tribulations of scrolling on the Amiga.

My oh my, this AGA coding just beat the shit out of me.

To get the best out of the AGA you need to use the machine in 32 bit mode (FMODE) so you can get full access to the speed for bitplanes or sprites. The problem is is that this has a lot of side effects (mainly unwanted) that you have to contend with... as I've just found out. I bet them console programmers don't have this bother.

Anyway, I've started work on the scrolling map as it's important I get this working along side the collision stuff.

This isn't working perfect yet, it's close but like I said it's beat me tonight, I'll sleep on it but I like to do regular updates.

For some reason the tiles are not coming in on the borders at the right times. I've had worse bugs though and fixed them so I doubt this will be any different. One thing I am fairly pleased with is the amount of processor time it's chewing up... compared to an A500 this is very favourable.

If I can fix it then the project will rapidly start to look like Rygar. Those numbered tiles are just for test, the map is 64 tiles wide by 12 depth... I'd just need to change the sizes and load the Rygar maps when I have it working.

[ Show youtube player ]

[DamienD]

I'm positive you'll work it and out and get there my friend