Klax, Atari ST to Jaguar conversion

[walter_J64bit]

Speaking of ST conversion whats up with Star Raiders? Since we'er talking ST conversion I'd like to see Loadrunner on the Jag. I've just founded out that Loadrunner is on the ST. LOL http://www.youtube.com/watch?v=8trhCJo3iYc

Edited January 31, 2014 by walter_J64bit

[+CyranoJ]

You have to wonder... prior to MAME, did anyone ever notice these differences? (Goes for most Arcade ports, I guess)

 

 

You'd probably have to see and play them to see how I see it. But maybe you wouldn't. The TG-16 version just seems like so much more care was put into the conversion than the Genesis version. Graphically its a lot better. A lot more attention to detail compared to the arcade.

 

[JagChris]

I noticed them and I did not play them on Mame.

[Lynxpro]

Wasn't Klax in the arcades done on a 6502? I know Atari Games' arcade version of Tetris was...

[Rybags]

Tetris uses a 6502 - most versions of that game don't have a great deal going on.

Klax uses a 68000.

 

There can be a fair amount of graphical action going on and it's psuedo-3D. No doubt a 6502 could handle it albeit suffering slowdown when things get hectic.

Chances are the Atari arcade Klax would have some degree of hardware assistance for the graphics, e.g. sprites or a blitter system.

[LinkoVitch]

CPU's in arcade machines aren't a worthy example of power. They generally have a bucket of fancy high end (for the time) custom silicon specifically built for throwing lots of things around the screen. The CPU probably just tracks player inputs and scores, all the real grunt work will be done elsewhere. Arcade boards don't exactly have a small budget or high run rate when they are being developed, not like a home computer/console, and can be very specific to the handful of games that they are designed to play.

[catsfolly]

Tetris uses a 6502 - most versions of that game don't have a great deal going on.

Klax uses a 68000.

 

There can be a fair amount of graphical action going on and it's psuedo-3D. No doubt a 6502 could handle it albeit suffering slowdown when things get hectic.

Chances are the Atari arcade Klax would have some degree of hardware assistance for the graphics, e.g. sprites or a blitter system.

The Klax arcade hardware could handle lots of sprites and a simple tiled background.

All the frames of the tumbling tiles were prerendered on a 3d system and stored as individual animation frames on the hardware.

 

The Genesis version was based on the arcade game code, but suffered because no one at Atari Games knew much about the Genesis hardware (especially the sound chips) at that time.

 

The Megadrive version was done independently at Namco in Japan.

 

The TG16 version was done by a Japanese programmer at Namco who was sent a video tape of the arcade game and replicated the game almost exactly in just a few weeks.

[Rybags]

From the research I did earlier, didn't find much about the graphics HW though, likely 256 colour bitmap mode, unknown if sprites, blit or object scaling available.

 

Klax was originally developed on the Amiga in Basic and was ported line by line to C. Atari then prototyped on an "Escape from the planet of the Robots" arcade setup.

 

Given the game has fairly wide representation on home systems and from obvious observation, the requirements aren't exactly high.

 

Anything an ST or Amiga 500 can do should be a walk in the park for the Jaguar in any case - disregarding stuff that uses ludicrous amounts of Ram or HDD storage.

[108 Stars]

The Genesis version was based on the arcade game code, but suffered because no one at Atari Games knew much about the Genesis hardware (especially the sound chips) at that time.

 

The Megadrive version was done independently at Namco in Japan.

 

The TG16 version was done by a Japanese programmer at Namco who was sent a video tape of the arcade game and replicated the game almost exactly in just a few weeks.

Thanks for the info, I was unaware that Klax is one of those cases where completely different western and japanese versions exist.

 

To the left is the Japanese version, to the right we have the US version.

 

 

I must say I find the US-version nicer visually. The Japanese version does have some voice samples though and the title screen with a spinning K. Spinning Ks are awesome. And the Japanese version is closer to the arcade (and pretty much like the PCE), but from a quick look I prefer the US one.

 

No music in either version.

Edited January 31, 2014 by 108 Stars

[catsfolly]

Thanks for the info, I was unaware that Klax is one of those cases where completely different western and japanese versions exist.

 

To the left is the Japanese version, to the right we have the US version.

 

Klax (Japan)001.pngKlax (USA)000.png

 

I must say I find the US-version nicer visually. The Japanese version does have some voice samples though and the title screen with a spinning K. Spinning Ks are awesome. And the Japanese version is closer to the arcade (and pretty much like the PCE), but from a quick look I prefer the US one.

 

No music in either version.

The Genesis version had music but it was disabled by default. It could be enabled on an option screen somewhere.

I always thought the Lynx version had the best music...

[GroovyBee]

Speaking of ST conversion whats up with Star Raiders?

Nothing! Its still there on my hard drive .

[VladR]

But it has 3D! You could unleash the POWA of the GPU and Blitter and make Klax 3D!!!!... and of course make everything run at 10FPS which would be a great feature for a frantic puzzle!

All sarcasm aside, from my recent experimenting with the Jaguar, the 68000 alone is actually more than powerful enough for a 3D Klax - meaning the camera could be dynamic - e.g. when you move the paddle from left <-> right, the camera would strafe accordingly.

 

I dare to say, that there might even be some performance left for antialiasing of the stones, from my experimenting with H.E.R.O. remake and antialiasing.

 

25 fps should be easily reachable, considering how little moves on screen (about 5 stones at most ?).

 

Although, personally I'd prefer it the stones just slid (and did not rotate) - sort-of like just lying on the conveyor belt. That would make the game feel much smoother and less blocky.

 

 

But yeah, it's perfectly doable, even in C and using just the old 68000...

[LinkoVitch]

Given the GPU running a very small amount of code in it's own local ram isn't fast enough to process a whole scanline from the OPs line buffer (I have tried this, found limits and have witnesses from e-Jagfest this year), and it's running are more than twice the clock speed of the 68K, single tick instructions, and only working with supafast SRAM. I seriously doubt there is enough grunt in the 68K to do all that you say. ESPECIALLY in C.

 

Of course, I am more than happy to be proven wrong by all means please knock together a rough demo of the tiles sliding down the ram and the camera panning as you describe.. from what you have done already I imagine this would be fairly simple for you to knock up?

 

Oh and is that 25FPS on REAL hardware or under VJ?

 

I don't doubt that Klax could be done using pure 3D on the Jag.. I don't think it would be the best look/feel however.

 

There is a lot of 2D power in the box, some scaling objects would look prettier, and you could even fake the 3D perspective and have buckets* of resource left over to add extra sparkle to the game.

 

*Buckets may actually resemble thimbles, but if you get up reeeaally close they look a bit bucket.

[108 Stars]

It's not the nineties anymore and there is no time for Klax.

[VladR]

If by 25 fps you mean "whole-screen redraw", then yes - it's not possible using just 68k (and most probably not even using all other silicons).

 

But, you really need to redraw whole screen only upon strafing, and even that would probably have to happen only 2-3 times per second at most - which is certainly doable.

 

But this is not FPS game where you could rotate or anything - you can merely strafe - thus the base background could be already prepared in a second buffer (say, a simple blit of 320x200 from the off-screen buffer with dimensions,say, 400x200) and you'd redraw merely the conveyor belt and the boxes - which if we're talking just about strafing, is just a simple blit operation (no expensive texturing).

 

Yes, the boxes would have to be redrawn upon every move, but I really doubt it would have to happen 25 times per second - especially the distant boxes move barely 3 pixels a second, so even the closest ones probably don't move more than 10-15 pixels per second. Boxes would not be textured, since it would be a pixelated mess at those few pixels anyway.

 

Plus, why redraw whole screen, when only, say, a region of 20x20 pixels changes ? Just grab the background beyond the cube, draw cube, then put those 20x20 pixels back and draw cube again.

 

To user, it would feel like 25 fps, even though - technically, the whole screen would not be prepared from scratch 25 times per second.

 

 

You are correct that using the framework I have already, it shouldn't take more than a day or two to knock up a simple self-running demo of the blocks on the conveyor belt redrawn on tot of some static background. I'm in the PC mode right now (for few more months), but maybe I could be talked into it, since this kind of coding does provide an instant gratification...

 

Of course, as always, all my benchmark numbers are from VJ, unless I specifically mention that someone tested it and provided some real HW numbers, thus they are inherently skewed and those of you who frequently switch between both VJ & real jag can tell by how much.

[+CyranoJ]

I've never managed to get your HERO demo to run at anything above 3fps, even in VJ, so I'd have to disagree that 25fps is achievable.

 

However, using a GPU sprite engine and forgetting about all that 3D gibberish, you could nicely manage 60fps.

 

In fact, if you did it in CRY mode, you could store ONE set of blocks in gray scale, and colour them in realtime to get all the tiles.

Edited February 14, 2014 by CyranoJ

[VladR]

HERO certainly does run in more than 3fps, even with vsync it's about 12 fps (if I remember correctly), but that redraws practically whole screen (fps actually scales almost linearly based on number of pixels redrawn), whereas klax would redraw how much - 5-10% of screen space, most of the time (save for strafing when we'd have to redraw the conveyor belt) ?

 

It should be easy to take a screenshot of the game via google and just measure how big the box is when it is closest to the camera. I doubt it's bigger than 25x25 pixels.

 

I guess that's where the confusion comes from - when I say 25 fps - I don't mean full-screen redraw - just redrawing those elements that change (e.g. the boxes that are about 25x25 pixels at most). The main loop processing input would get those 25 fps.

 

That catcher-thingy could be just a sprite (perhaps, prerendered under 5-15 different angles to give the illusion of 3d space) that would be merely blitted.

 

 

60 fps would be a waste of performance on such game, though. I'm pretty sure you could not even see it, nor feel it in controls.

[+Gemintronic]

Maybe someone should resurrect GroovyBees idea here:

http://atariage.com/forums/topic/167701-stos-for-jaguar-possible/?do=findComment&comment=2669531

 

Let some poor soul writing C and asm libraries do the optimization (and joystick functions) for you

 

..and by poor I mean it sounds like a thankless job filled with half wrong documentation and unknowns.

[LinkoVitch]

Let some poor soul writing C and asm libraries do the optimization (and joystick functions) for you

 

..and by poor I mean it sounds like a thankless job filled with half wrong documentation and unknowns.

 

Looks like this has almost already been done... http://www.u-235.co.uk/inclusion-in-rebooteroids-furthering-feature-development/

 

And pads are a bit messy, but not exactly rocket science but hey, not long now and you'll not need to bother with talking to that hardware directly anyway

 

 

VLADr, I think CJ (and myself) know what fps are, it is irrelevant how the screen is drawn, the number of updates per second are what matters, and on real hardware. Theoretical discussions can be interesting, but they are just that, theory. Until you put it into practice it's just an idea. I don't get why you seem to want to do everything in 3D when the same things could be done with 2D simply and give a much smoother result. but then, why are any of us poking a 20yr old bit of hardware We do it for fun, I'd be interested to see your ideas on klax style 3D game.. I am still not convinced it's the best approach, and it sounds like you are overlooking key parts of teh jag hardware and don't yet fully grasp it's strengths or how it functions.

[+CyranoJ]

68000 only

 

Superfly DX - Video

 

You'd be quite surprised what the 68000 can actually do.

 

If by 25 fps you mean "whole-screen redraw", then yes - it's not possible using just 68k (and most probably not even using all other silicons).

 

[BillyHW]

I wouldn't even know how one version of a game like Klax could blow another one away. It's a freakin' puzzle game, no graphical master piece with astonishing graphics effects.

 

The only way to screw up Klax is probably to do it in black & white.

 

 

You can still screw up the controls. See the pretty bad C64 port.

[VladR]

Why 3D ? Well, simply because of the challenge & fun factor. Doing Klax in 2D would be a boring exercise of placing the pre-rendered sprites properly. There's no fun in coding that. If one even used Blitter, jag would not even break a sweat and would do it probably even in 300 fps (assuming you could program HW to that kind of timings). It certainly has a horsepower to do do game like Klax in such an absurd framerate.

 

It does seem to me that 3D could actually alter the gameplay a bit - sort-of going towards Break-Out - style gameplay.

 

For example - you could gradually build 3 different layers (each being 3x3 grid), thus in the end you would have a cube 3x3x3. During game you would have to switch between the layers and keep a mental image of their contents.Perhaps you could switch between the layers only a certain amount of times - which would give the game a slightly strategic touch.

 

Or you could build some other voxel stuff - sort-of like in a MineCraft - smaller irregular objects and after each level the camera would rotate and zoom in/out around that object. Points would be awarded based on precision of each layer.

You would see the final result - all layers placed one above another, only at the end.

 

If one wanted, he could even add some simple physics to it, thus each cube/block would fall, if it wasn't supported by other cubes below it - I'm talking just a basic simple gravity equations here (few lines of code in C) - nothing fancy as in PhysX, of course !

I guess we all noticed that physics adds another layer of immersion and replayability to the game.

 

 

That's just first two ideas from the top of my head, but the point is that 3d gives you opportunities you do not have with 2D.

[sh3-rg]

Not exactly sure what would prevent any of those ideas being realised with objects (sprites).

 

When it comes to making games, I'm always of the opinion that you keep the mechanics simple and solid and turn up the sex after that if needed. While bizarre cross-overs sometimes lead to interesting new concepts, sometimes they give birth to something bigger than the sum of the parts... but usually they just end up being frustrating and annoying in with their missed potential (even the Jaguar has perfectly suitable examples here).

 

I guess what you coder kids are all saying is that you enjoy programming for different but understandable reasons, and the end result is sometimes not as high up the list of important factors than the journey that takes you there. I get that...

but think you're all a bit fucking weird tbh.

 

[+Stephen]

25fps - ick. This game was killer on the Lynx, had digitized sound, and ran silky smooth.

[VladR]

So, I played a bit with my 3D rasterizer in C yesterday, tweaked it a bit to get the proper perspective and came up with this

 

The Conveyor belt is procedurally generated, same goes for cubes [obviously].

 

I also implemented a run-time shading based on depth of the pixel.

I have to tweak the cube rendering, since they are slightly higher than they should be, because the underlying codebase was meant for screen-height walls, not just few pixels.

 

JagChris : Now you can't say that no one ever tried to make Klax for Jag

 

Disclaimer: No GPU was harmed during production of this demo