Jump to content
IGNORED

ABBUC Software Contest 2007


Bunsen

Recommended Posts

emkay...you precalculate the texture offsets mapped on the tunnel...these offsets are fixed as the camera is not moving. so if these are fixed...you know where on screen you have to put which texel ("pixel in texture"). so again...all is predefined so you can generate a long code loop which does nothing as f.e.

 

lda texture1+offset a,x

ora texture2+offset b,x

ora texture3+offset c,x

ora texture4+offset d,x ; as gr.7 has 4 pixel per byte

sta screen

lda texture1+offset e,x

ora textzue2+offset f,x

...

 

so...the offsets are fixed values which you get by doing the "3d-2d-transformation" on screen. but how do you scroll? well... this could be done via the index register X...

 

but thats just a untested one...i am not sure if Eru did it in that way but this is how in general you are doing a texture tunnel which in Yoomp is used...

 

on Amiga you would do something like Move.w offset(texture),(screen) if i remember it correct...

Link to comment
Share on other sites

Fröhn... but you know that trailblazer is far more simpler? as you have a simple 3 colour bitmap gfx where DLIs or Rasterinterrupts doing the movement and the changes of the blocks. on the Atari version you can see that everything is consisting of 3 colours and the patterns are reflecting that.

 

i studied Trailblazer long time ago as i wanted to do a 1k verion of the game years ago but lost the complete source code of the prototype. but Eru did it now in a better way... ;)

Link to comment
Share on other sites

I never found Trailblazer any fun. Unplayable. Yoomp is fun. Easy and challenging enough

at the same time.

 

Congrats and 'Thank you' to all coders, all programs are quality productions.

I played Speed up on the JHV - we had a little tournament going on 4 networked XLs.

Now i need those network interfaces. with opponents it makes more fun as the

Abbuc contest scores reflect. Also Eckn makes more fun after you played several games.

Same applies to Mulewars. Not exactly the genre i play usually, but i like it.

 

Regards,

Beetle

Edited by Beetle
Link to comment
Share on other sites

Fröhn... but you know that trailblazer is far more simpler?

 

Oh, i'm sure he's perfectly aware of how it works... and yes, obviously it's more simple but the point is that the difference between the two technically isn't as large as was being implied. In both cases they're taking a 2D game area and displaying it in pseudo 3D, one is about twenty years older than the other and it was just as much a wow factor when it was released as Yoomp has now.

Link to comment
Share on other sites

Has anyone created an ATR file from crownland.xex? I want to play it on my real 130XE. I tried several times but I can't seem to get it to load from DOS. I tried MyDOS, PicoDos, Dos 2.5. Crownland starts to load but then just stops. Is there a bootloader I should be using? Any help would be apprteciated.

 

 

The demo version of it ran just fine from SpartaDOS with BASIC disabled..

Edited by MEtalGuy66
Link to comment
Share on other sites

Has anyone created an ATR file from crownland.xex? I want to play it on my real 130XE. I tried several times but I can't seem to get it to load from DOS. I tried MyDOS, PicoDos, Dos 2.5. Crownland starts to load but then just stops. Is there a bootloader I should be using? Any help would be apprteciated.

 

 

The demo version of it ran just fine from SpartaDOS with BASIC disabled..

 

Yep, I can get the demo version to run just fine, but not the new full version. I didn't try SpartaDOS. I will try that next. Thanks for the suggestion.

Link to comment
Share on other sites

emkay...you precalculate the texture offsets mapped on the tunnel...these offsets are fixed as the camera is not moving. so if these are fixed...you know where on screen you have to put which texel ("pixel in texture"). so again...all is predefined so you can generate a long code loop which does nothing as f.e.

 

lda texture1+offset a,x

ora texture2+offset b,x

ora texture3+offset c,x

ora texture4+offset d,x ; as gr.7 has 4 pixel per byte

sta screen

lda texture1+offset e,x

ora textzue2+offset f,x

...

 

so...the offsets are fixed values which you get by doing the "3d-2d-transformation" on screen. but how do you scroll? well... this could be done via the index register X...

 

Why call "Pre calculating" a trick (remembering the "littte" difference between rendering and full raytracing) ? And what will make it impossible to change the "camera view" when already a "zooming" is done? The game already does more than a simple tunnel. It handles different Tiles and Rules for the gameplay. So there are much more complex routines for the gameplay running than a repeatable subroutine.

 

The only difference between such a tunnel and the 3D Games on PC and nextgen Consoles is the amount of used elements. The most of graphics is "Pre calculated" even in those games. Making a difference of 1:1000000 of Data on the "CD/DVD)".

Link to comment
Share on other sites

Yep, I can get the demo version to run just fine, but not the new full version. I didn't try SpartaDOS. I will try that next. Thanks for the suggestion.

 

Do you know "Micro SpartaDOS" ... that is a Binaries loader for spartados. You can run this 'MSDOS.COM' (I like that name haha) from the D1: prompt, or you can make your sparta partition bootable with it.

 

It comes with an INI file, so you can label the files with long filenames.

 

It is just like PicoDos from Hiassoft, for SpartaDOS format.

 

I'm very happy with it.

 

It does not work with the MyIDE interface, but I made some changes to it, so now it also works with MyIDE.

 

Let me know if you are interested. Crownland binary runs fine from MSDOS.COM

Marius

Link to comment
Share on other sites

Why call "Pre calculating" a trick (remembering the "littte" difference between rendering and full raytracing) ?

 

Because, just like any other trick (sprite- or colour-based) they appear to be doing more than is actually going on.

 

And what will make it impossible to change the "camera view" when already a "zooming" is done?

 

The problem is that you're thinking of things in 3D whilst the game isn't emkay, there are no elements, no objects, no camera here in the same way there aren't in Trailblazer; the shape of the tube is pre-rendered and stored as a 2D object, the routine that translates the 2D play area into the display doesn't think in 3D, merely in transpositions of cells from point A to point B. You're being fooled basically, even something simple like Outrun on the C64 is doing far more complex on-the-fly handling of it's environment.

 

The game already does more than a simple tunnel. It handles different Tiles and Rules for the gameplay. So there are much more complex routines for the gameplay running than a repeatable subroutine.

 

All of that is running from the 2D plane in memory and you're wrong, it's a very easily repeatable subroutine and in fact the collisions are easier than something like Crownland because the player only moves on one axis here. Comparing for different tiles and reacting accordingly is hardly rocket science, Trailblazer does it too.

Link to comment
Share on other sites

Why call "Pre calculating" a trick (remembering the "littte" difference between rendering and full raytracing) ?
Because, just like any other trick (sprite- or colour-based) they appear to be doing more than is actually going on.
I've never really liked that terminology before either to be honest, I prefer to say technique rather than trick. It's true to say that achiving the desired result with these techniques makes it look like more is going on but it's the end result that matters, our limited machines are incapable of doing many of the things we want to do in a real game environment for "real". Do we really care if it's pseudo 3D? perhaps only on a technical interest level.. The audience only care that the end product looks good and plays good
Link to comment
Share on other sites

emkay... in German: Yoomp ist komplett 2d. Auch Trailblazer ist 2d. da ist keine einzige 3d-Kalkulation im Code. Yoomp könnte auch komplett in 2d laufen. einfach den Tunnel auffalten und die Kamera von Oben auf die Fläche zeigen lassen... Das was du als "3d" siehst ist eine Illussion. Die Zeichenroutine verwandelt aus den 2d Textur-Daten, d.h. die Flächen, einen Tunnel, d.h. rendered. Aber im Code selber ist da keine Transformation oder gar Berechnung des Tunnels drin oder die Perspektiven-Korrektur. Da der Tunnel sich nicht bewegt, sind alle notwendigen aufwendigen Berechnungen fix, d.h. die kannst du in Basic vorher machen und eben die Sachen "prerendern", d.h. die fixen Positionen. In Yoomp wird es nicht möglich sein, z.b. die Kamera zu verändern oder zu Zoomen oder etc... Das "Bewegen im Tunnel", d.h. das Scrolling wird normalerweise einfach durch das verschieben der Textur im Speicher erreicht bzw. durch veränderte Offsets. Der "Tunnel-Code" bringt dann diese wieder auf den Schirm als eben einen Tunnel, aber aufpassen. Wiederum keine Berechnungen hier... der Code ist so präpariert, dass er einfach das so macht, nimm das Pixel der Textur 1 und schieben es auf die Bildschirmposition X,Y... wenn ein Pixel mehrmals gezeichnet werden muss, wegen der Perspektive, dann steht im Tunnel-Code eben nimm das Pixel der Textur 1 und schiebe es an Bildschirmposition X+1,Y usw... und diese Positionen, d.h. welches Pixel muss wo hin auf dem Schirm ist für alle (!) Texturen vorherbestimmt, weil eben die Kamera und der Zoom fix sind und daher leicht vorherzuberechnen. Würde Yoomp! die Kamera drehen wirds schon kniffliger, weil du dann "dynamisch" Berechnungen machen musst und eben nicht alles so vorberechnen kannst.

 

ok... later i will do the english translation. hope that's ok for the non-german ones....

Link to comment
Share on other sites

Yep, I can get the demo version to run just fine, but not the new full version. I didn't try SpartaDOS. I will try that next. Thanks for the suggestion.

 

Do you know "Micro SpartaDOS" ... that is a Binaries loader for spartados. You can run this 'MSDOS.COM' (I like that name haha) from the D1: prompt, or you can make your sparta partition bootable with it.

 

It comes with an INI file, so you can label the files with long filenames.

 

It is just like PicoDos from Hiassoft, for SpartaDOS format.

 

I'm very happy with it.

 

It does not work with the MyIDE interface, but I made some changes to it, so now it also works with MyIDE.

 

Let me know if you are interested. Crownland binary runs fine from MSDOS.COM

Marius

 

I am interested. Where do I find micro SpartaDOS I also have the MyIDE interface so both versions would be helpful.

Thanks!!

Link to comment
Share on other sites

ok...now the english summary:

 

Yoomp and Trailblazer are pure 2d simply because there is no 3d calculation in the code. so yoomp could be working complete in 2d if you unfold the tunnel and put the camera above to look directly on the field. so the 3d-effect is a complete illusion. the draw routine is taking the 2d texture data and puts them on screen like an tunnel so actually rendering. but you will not find any transformation or calculation algorithms in the code. as the tunnel is not moving you can simply precalculate all necessary calculations in basic f.e. so you "prerender" the fixed pixel positions. I assume that it is not possible to move the camera or turn the tunnel in Yoomp!. The "Movement" of the tiles in the tunnel is an illusion as well as the textures are moved around in the texture buffer via altering offsets or by altering the texture buffer. the tunnel-draw code is taking this texture buffer and renderes them on screen but beware. again no calculation here. the draw code is prepared in that way that it only takes pixel from the texture buffer and puts them on screen position x,y. if a pixel needs to be drawn several times (because of the perspective or of the zooming) the draw code was told to put the same pixel on position x+1,y f.e. etc. and the information which pixel needs to be put on which screen position to get the tunnel rendered is fixed. as the camera is fixed and the zooming is fixed as well. so you can easily prerender the offsets and the positions. if Yoomp would move the camera around for small turns it would be far more difficult as you then would need dynamic calculations.

Link to comment
Share on other sites

Even if the technique is a hidden 2D style, all these stuff should be require CPU power, is at 25/30 fps and I never seen before a similar game on any 8bit machine.

 

 

That's hits the spot. Switching some colours by rasters and to check the sprite collisions really has nothing to do with 3D, while Yoomp does really full graphics updates in a respectable speed.

And, ofcourse there are no 80 bit floating point 3D calculations. But all necessary is done to have the right look and feel of a 3D environment.

Link to comment
Share on other sites

Even if the technique is a hidden 2D style, all these stuff should be require CPU power, is at 25/30 fps and I never seen before a similar game on any 8bit machine.

 

That's hits the spot. Switching some colours by rasters and to check the sprite collisions really has nothing to do with 3D

 

Moving some 2D tile data around and checking sprite collisions has nothing to do with it either, both generate a sense of 3D motion and Yoomp does a better job (and considering the age difference, i should bloody hope it does too!) but they are both based exclusively on 2D data and you can see that where the holes are on either game; there's no third dimension there because they're not dealing with it.

Link to comment
Share on other sites

Why call "Pre calculating" a trick (remembering the "littte" difference between rendering and full raytracing) ?
Because, just like any other trick (sprite- or colour-based) they appear to be doing more than is actually going on.
I've never really liked that terminology before either to be honest, I prefer to say technique rather than trick.

 

i don't use the word trick either personally, but emkay used the terms "sprite trick" and "raster trick" if memory serves and precalculation is no more or less a trick than they are. Since a lot of the disagreements i've had in the past with emkay have resulted from terminology issues, i find it easier to work with the words he's using than my own occasionally.

 

Do we really care if it's pseudo 3D? perhaps only on a technical interest level.. The audience only care that the end product looks good and plays good

 

i care only in that the game underneath what's going on is almost identical to Trailblazer but there's an awful lot of shouting about how original this is... yes it looks great although i can't comment on the playability yet (bad time for me to be playing games to be honest, i'll sit down and give it a proper go next week) but reading some of the posts here you'd believe it was this ultra original, never seen before game... and it's not, the authors have said it's not on the official site for crying out loud.

Link to comment
Share on other sites

yes it looks great although i can't comment on the playability yet

IMHO the gameplay is excellent. The first few levels are not too hard and let you become familiar with the controls and game features (long jumps, teleporters etc.). With each level it gets trickier. Currently I'm stuck at level 14 which is quite hard (at least for an occasional game player like me), and I'm really curious about what levels 15-21 will look like.

 

The game control is extremely precise, the graphics is fast and nice, and this alltogether makes it a perfect (and very addictive) game for me.

 

After playing Yoomp! for a while I made a direct comparison with Trailblazer (both games are similar, and Trailblazer immediately popped into my mind).

 

Personally I find Trailblazer is too hard. It's faster then Yoomp! and the game controls didn't seem to be as precise as in Yoomp!. When I first played Trailblazer some 20 years or so ago, it was similar. The graphics looked great (for that time) and the idea was really nice, but I always quickly gave up.

 

So - for me - Yoomp is the better conversion of the game idea. Not necessarily because of the great graphics and sound (which are really amazing BTW), but mainly because of the better overall gameplay.

 

so long,

 

Hias

Link to comment
Share on other sites

This discussion is making me crazy, so I decided to speak up.

 

Indeed, one can see Yoomp! as a 2D game with a special map. And, as the development page states, it is based on the 'Tube' game, that follows the same principle. Also, similar effect has been seen in many demos on Atari, starting with the 'Recycle' intro (intro part of the intro:)): http://www.pouet.net/prod.php?which=9830

 

We tend to stretch things to call them 3D. After all, many people call Zaxxon a 3D game. But what is 3D? On PC, many people say Wolfenstein 3D was not really 3D, as it was just a projection of a 2D world. The same some said about Duke Nukem 3D. And Doom.

So, when it comes to 'faking' 3D, whatever works, works.

But where is the border? Is Road Race a 3D game? Is Trailblazer? Is Yoomp!? Is Alternate Reality? Is Rescue from Fractalus? The border can be at any point in this list - it all depends on how you look at it, so the entire discussion is pointless.

 

When it comes to the gameplay, many people compare Yoomp to Trailblazer. Frankly, I didn't even think about Trailblazer when working on it, but now I see some similarities. My idea was to take Jump! and make it 3D, and then I had an idea of extra tiles. And that was it.

 

Finally, some words about the engine. The real problem is not how to do it, as many demos have shown it, but more of how to do it with high resolution, fast and in 64KB at the same time. Turns out, the last problem is the hardest.

As Heaven pointed, the code follows an idea found in many demos. The idea is, for each pixel on the screen, we know which pixel from the texture we must plot, and by changing the offset into the texture, we get an impression of animation.

The code is roughly like this:

LDA texture_data + some_offset0,Y 
ORA texture_data + some_offset1,Y 
ORA texture_data + some_offset2,Y 
ORA texture_data + some_offset3,Y 
STA screen,X

Here, some_offset depends on 3 things: position of a pixel in a byte (4 possibilities), x position of a pixel in the texture (64), and y position of a pixel in the texture (64).

X is used for double-buffering and a screen trick mentioned below. And Y contains the current index into the texture buffer.

You can see such code starting at address $400. This code in a 'default' approach takes ca. 25KB for this tunnel map.

This code is long as it is unrolled, but the thing is it CAN'T to in a loop, for two reasons, 1) the parameters would be variable making it very slow, 2) the loop overhead would make it even slower.

Now, textures. What you see is a 8x4 tiles map, of 8x16 tiles (actually, 8x8 texture, but stretched for smoother animation), hence 64x64 pixels map. So this needs immediately 4KB. Now, multiply it by 2, since we need a 'looped' texture to allow fast scrolling through it. That's 8KB. Now, multiply it by 4, since we need separate texture for each GR.7 pixel. That's 32KB.

So, 25KB + 32KB = 57KB used by a 'default' engine. Oh, and +3KB for the screen memory = 60KB. Not much left for anything else, right?

So, the optimizing started. First thing was a clever hack that allows the same code to draw the lower and upper part of the screen, by proper tunnel data, texture and screen organization. This reduces the code by half to 12.5KB, without sacrificing any visual quality.

The second trick was to reduce the horizontal tile resolution by half and use a mirror - this reduces the texture space by 2, but limits the design of the tiles - they all need to by Y-symmetric, as you can see.

Still, even with these approaches the engine+screen take 31KB. Add lots of code, main menu (zipped), levels (zipped), backgrounds (zipped), music, end-of-the-game screen (I think zipped, can't remember now), fonts, name it.

I personally consider this my greatest programming achievement at Atari.

 

Oh, and I really like Crownland :)

Link to comment
Share on other sites

This discussion is making me crazy, so I decided to speak up.

 

Indeed, one can see Yoomp! as a 2D game with a special map. And, as the development page states, it is based on the 'Tube' game, that follows the same principle. Also, similar effect has been seen in many demos on Atari, starting with the 'Recycle' intro (intro part of the intro:)): http://www.pouet.net/prod.php?which=9830

 

We tend to stretch things to call them 3D. After all, many people call Zaxxon a 3D game. But what is 3D? On PC, many people say Wolfenstein 3D was not really 3D, as it was just a projection of a 2D world. The same some said about Duke Nukem 3D. And Doom.

So, when it comes to 'faking' 3D, whatever works, works.

But where is the border? Is Road Race a 3D game? Is Trailblazer? Is Yoomp!? Is Alternate Reality? Is Rescue from Fractalus? The border can be at any point in this list - it all depends on how you look at it, so the entire discussion is pointless.

 

There are enough people saying that modern 3D games are not real 3D. And they are almost right. Using millions of objects in a 3D Room and with multiple overlayed shaders isn't real 3D.

F.e. . When the coder wants some reflections on the water, he has to create them separately. The objects don't have real "3D" dependings for reflections, so every reflection has to be calculated as the object itself.

 

Creating real 3D games with full 3D environment.... well, I gues we need to wait another 10 (or so) PC generations...

 

When it comes to the gameplay, many people compare Yoomp to Trailblazer. Frankly, I didn't even think about Trailblazer when working on it, but now I see some similarities. My idea was to take Jump! and make it 3D, and then I had an idea of extra tiles. And that was it.

 

Finally, some words about the engine. The real problem is not how to do it, as many demos have shown it, but more of how to do it with high resolution, fast and in 64KB at the same time. Turns out, the last problem is the hardest.

As Heaven pointed, the code follows an idea found in many demos. The idea is, for each pixel on the screen, we know which pixel from the texture we must plot, and by changing the offset into the texture, we get an impression of animation.

The code is roughly like this:

LDA texture_data + some_offset0,Y 
ORA texture_data + some_offset1,Y 
ORA texture_data + some_offset2,Y 
ORA texture_data + some_offset3,Y 
STA screen,X

Here, some_offset depends on 3 things: position of a pixel in a byte (4 possibilities), x position of a pixel in the texture (64), and y position of a pixel in the texture (64).

X is used for double-buffering and a screen trick mentioned below. And Y contains the current index into the texture buffer.

You can see such code starting at address $400. This code in a 'default' approach takes ca. 25KB for this tunnel map.

This code is long as it is unrolled, but the thing is it CAN'T to in a loop, for two reasons, 1) the parameters would be variable making it very slow, 2) the loop overhead would make it even slower.

Now, textures. What you see is a 8x4 tiles map, of 8x16 tiles (actually, 8x8 texture, but stretched for smoother animation), hence 64x64 pixels map. So this needs immediately 4KB. Now, multiply it by 2, since we need a 'looped' texture to allow fast scrolling through it. That's 8KB. Now, multiply it by 4, since we need separate texture for each GR.7 pixel. That's 32KB.

So, 25KB + 32KB = 57KB used by a 'default' engine. Oh, and +3KB for the screen memory = 60KB. Not much left for anything else, right?

So, the optimizing started. First thing was a clever hack that allows the same code to draw the lower and upper part of the screen, by proper tunnel data, texture and screen organization. This reduces the code by half to 12.5KB, without sacrificing any visual quality.

The second trick was to reduce the horizontal tile resolution by half and use a mirror - this reduces the texture space by 2, but limits the design of the tiles - they all need to by Y-symmetric, as you can see.

Still, even with these approaches the engine+screen take 31KB. Add lots of code, main menu (zipped), levels (zipped), backgrounds (zipped), music, end-of-the-game screen (I think zipped, can't remember now), fonts, name it.

I personally consider this my greatest programming achievement at Atari.

 

Oh, and I really like Crownland :)

 

You did a great job, and it was honored correctly.

Crownland is great, too. But, as you may see at your own writings, it uses "old" techniques with a clever combination. And the graphics are done well. But you did really something new for the A8.

And, I still cannot understand why people compare Yoomp with Trailblazer....

Well, I have a theory...

Having such game on the C64, the "Computerworld" would have given "3D" a new definition. But it's done on the ATARI ....

If you know what I mean ;-)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...