Old school platformer comes to the jag

[GroovyBee]

Today was the first day of the Video Olympics event at the Lass O'Gowrie pub in Manchester, UK. For a laugh I ported the SDL version of A&F's Chuckie Egg originally reverse engineered into "C" (from the BBC micro version) by Paul Brook over to the jag. The jag is so hard to program for, that it took a massive 3 hours (last night) to rip out the SDL code and replace it with jag code to get it running at a decent frame rate :-

 

 

Photo of it running on real hardware (NTSC) :-

 

 

The original code is GPL'd so I'll be releasing the source along with a binary image. I doubt there will be an NTSC release because the games needs 256 vertical scan lines. There have been adaptations of the game in the recent past that have reduced the vertical screen requirements so I may go down that route.

 

Many thanks to Linkovitch and sh3-rg for testing. The game caused a few laughs and plenty of smiles and was therefore a complete success in my eyes.

 

There are no plans for a CD or cart run.

[LinkoVitch]

Just force it into interlace mode and geta nice picture of a BBC CUB monitor to act as a surround for the reduced play-area size should take not long to get it working and would look win

 

g'awn, you know it will look awesome and makes sense

[GroovyBee]

Just force it into interlace mode and geta nice picture of a BBC CUB monitor to act as a surround for the reduced play-area size should take not long to get it working and would look win

 

g'awn, you know it will look awesome and makes sense

 

I might just put that in .

[Tyrant]

Looking good.

 

Don't interlace it though, all those single-pixel lines would flicker like crazy. I guess you could interlace it and then have it stretched 2:1 but that wouldn't really help.

[JagChris]

Congrats GroovyBee! Too bad about the NTSC thing.

[GroovyBee]

Looking good.

 

Thanks for the compliment. It plays exactly like the BBC version so its a very good reverse engineering job by Paul Brook.

 

Don't interlace it though, all those single-pixel lines would flicker like crazy. I guess you could interlace it and then have it stretched 2:1 but that wouldn't really help.

 

If I can find a volunteer for the graphics I might have updated and classic modes. I don't really want to spend too long on it because it was a "make people laugh" kinda project.

[GroovyBee]

Congrats GroovyBee! Too bad about the NTSC thing.

 

Thank you! As I mentioned other versions need less screen real estate so its just a matter of borrowing the level data and it should just work.

[+CyranoJ]

You could try writing the screen to a scaled bitmap, and use the OP to shrink it down to NTSC size - that way there's no code needed!

 

Well done, GB!!

[GroovyBee]

You could try writing the screen to a scaled bitmap, and use the OP to shrink it down to NTSC size - that way there's no code needed!

 

Its mainly score, lives and timer and a big yellow bird taking up most of the top of the screen. It was just a fun little project to take to the event today. As soon as it was going I pretty much called a halt on it . It needs a bit more work to get the frame rate higher and then with a title page and high scores its pretty much done.

 

Well done, GB!!

 

Thanks for the compliment.

[LinkoVitch]

Looking good.

 

Don't interlace it though, all those single-pixel lines would flicker like crazy. I guess you could interlace it and then have it stretched 2:1 but that wouldn't really help.

 

They shimmer a bit, but I haven't really noticed too much flickering, plus if you run it through a half decent LCD it tends to buffer the fields and you get a solid image

[+Gemintronic]

Compilation time! Include Manic Miner and Jet Set Willy!

[Zerosquare]

You could try writing the screen to a scaled bitmap, and use the OP to shrink it down to NTSC size - that way there's no code needed!

Nah, don't do that. The OP doesn't use interpolation, and it'll look like crap.

 

Force 50 Hz mode instead

[walter_J64bit]

Keep up the good work! I hope a to see a NTSC fix.

[GT Turbo]

Very great work GB !!!!!

 

Yes very hard to code !!! xD Another example !!!!!

 

 

 

GT

[GroovyBee]

Compilation time! Include Manic Miner and Jet Set Willy!

 

I'd like to bring those over to the 7800 at some point way, way down the line.

[GroovyBee]

Keep up the good work! I hope a to see a NTSC fix.

 

Its certainly possible. It just makes the game a bit harder because you have less room to move around in to avoid the big duck when its released from the cage.

[GroovyBee]

Very great work GB !!!!!

 

Thanks for the compliment but I think Paul Brook deserves a lot more credit. He did all the really hard work in reverse engineering the original BBC micro 6502 game into working "C" code.

 

Yes very hard to code !!! xD Another example !!!!!

 

The jag just gives you more options to solve your in-game problems so there is never an "ultimate" single solution. Game coding is always a trade off between the resources the machine offers you, what you need to do behind the scenes in the game and what experience you have coding/debugging etc.

[walter_J64bit]

Keep up the good work! I hope a to see a NTSC fix.

 

Its certainly possible. It just makes the game a bit harder because you have less room to move around in to avoid the big duck when its released from the cage.

I've got an idea, You'd played Jr. Pac-man right? You know how the maze move with Jr Pac-Man when you go left or to right of the maze maybe you can do the same for your game instead the maze moving left to right just make where it move down and up that way you don't to have re-size your levels or do something more like Gauntlet or Dark Chambers.

[Tyrant]

Just force it into 50hz. I know almost all PAL TV's will accept PAL60 (NTSC size) signals. I'm sure the majority of NTSC screens should be able to accept PAL size signals, especially the more modern ones.

[GroovyBee]

I've got an idea, You'd played Jr. Pac-man right? You know how the maze move with Jr Pac-Man when you go left or to right of the maze maybe you can do the same for your game instead the maze moving left to right just make where it move down and up that way you don't to have re-size your levels or do something more like Gauntlet or Dark Chambers.

 

Possible, but you have to get on and off lifts in later levels so having the screen scrolling up/down would affect how you play the game. It'll be easier to alter the levels and then the play mechanics are what Chuckie Egg fans expect .

[GroovyBee]

Just force it into 50hz. I know almost all PAL TV's will accept PAL60 (NTSC size) signals. I'm sure the majority of NTSC screens should be able to accept PAL size signals, especially the more modern ones.

 

I'd rather just alter the level layouts. The Acorn Atom had a Chuckie Egg port recently and that has a comparable vertical resolution to an NTSC console (approximately 200 scan lines).

[Zerosquare]

Just force it into 50hz. I know almost all PAL TV's will accept PAL60 (NTSC size) signals. I'm sure the majority of NTSC screens should be able to accept PAL size signals, especially the more modern ones.

Actually, that was more or less a joke

AFAIK, there are a lot more NTSC TV sets that don't support 50 Hz than PAL set that don't support 60 Hz. So it's probably not a wise solution.

Edited August 5, 2012 by Zerosquare

[atarilovesyou]

Off topic, but when people say that the Jag is notoriously difficult to program for, what does this mean?...is it that there's no software developer tools to allow easier programming? I'm curious, but something tells me the answer must be a complex one as well.

[Tyrant]

Just force it into 50hz. I know almost all PAL TV's will accept PAL60 (NTSC size) signals. I'm sure the majority of NTSC screens should be able to accept PAL size signals, especially the more modern ones.

Actually, that was more or less a joke

AFAIK, there are a lot more NTSC TV sets that don't support 50 Hz than PAL set that don't support 60 Hz. So it's probably not a wise solution.

Really? Well that's a bit poo, isn't it?

I wonder how NTSC HDTV sets handle things?

Then again, a lot of HTDV sets don't seem to like the non-interlaced signals the Jag and other old games systems produce anyway.

[GroovyBee]

Off topic, but when people say that the Jag is notoriously difficult to program for, what does this mean?...is it that there's no software developer tools to allow easier programming? I'm curious, but something tells me the answer must be a complex one as well.

 

There are a lot of myths about the jaguar and this is one of them. I haven't had a problem with the official development kit documentation so far. The only problem is a lack of source code examples in the actual docs themselves because you have to go off and look them up (and then they might not actually do what you want them to do ). I don't have an Alpine or an archive of the official set of example code that came with the dev kits either. But with the availability of useful information on the Internet (Jagware, AtariMuseum etc.) and files Curt Vendel has put out to the community its not such an issue these days.

 

If you've done any moderately complex programming in assembler then the jag isn't a problem. If you've never got your head around how high level language concepts like arrays, linked lists or bit packed structures actually work at a low level then constructing an object list for the jag's object processor is going to be a problem. But having said that once you get some code that works it becomes part of your personal programming library and gets adapted and used in your projects as time goes on.

 

Sure the jag has its quirks and silicon bugs but you have to learn to live with them and to work around them when you need to. That is all part of developing your game. Its "you vs the machine" to get it to meet/exceed your goals and thats the fun part. Well... to me it is .

 

Writing games is always a trade off. With jag development these days you can write your game in "C" with "heavy load" parts moved out to the blitter and object processor and 68k assembler if needed. If you have a more demanding game then you offload parts to the GPU and make use of some architecture parallelism. There is no perfect solution to a game. Its all down to the game style/genre, personal choice/ability and what makes it fun for you as a developer. If you want to wring out every ounce of performance from the jag you can. If you want to write a simple game every month you can. Just have fun doing what you want to be doing.

 

With Reboot's RAPTOR engine on the horizon and U235's sound engine already available then the entry point to developing games on the jag in the future is coming down.