Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

R0ger

Members
 View Profile  See their activity

  • Content Count

    753

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by R0ger

  1. Posted · Edited by R0ger

    After recent releases of Bad Apple for Atari 800 and Sinclair I kinda got infected and I simply had to try myself. So here is my version !

     

    So far there is only cartridge version. It uses 8mbit Maxflash cartridge, it's also tested with Ultimate cartridge. I'm working on ATR version which will need 1MByte extended RAM, but this version only needs standard 64k Atari .. and the cartridge of course.

     

    If you use it with emulator, and have to select cartridge type, choose Maxflash 8MBit, old or new type, both should work.

     

    There are 2 draw modes .. scanlines and filled. Scanlines look less blocky, it looks good especially on CRTs. Sadly LCDs often process the image too much and the lines don't look good .. that's where the fill mode is useful. Or if you prefer the look ..

     

    The video plays at constant 12.5 FPS, resolution is 256x96. Animation itself takes cca 860k.

    There are 2 versions of the music, stereo and mono, detection is automatic. Stereo version is of course lot better and recommended.

     

    So enjoy !

     

    Youtube version (from Altirra):

     

     

    PS: If you can't get the song out of your head, sorry about that. Trust me, I know the feeling ..

    BadApple.1.0.zip

    • Like 32

  4. Posted

    I actually didn't play Elite either. I've seen it on my cousin's C64. Maybe docked once or twice. But never really played it. I did play Frontier, and Frontier First encounters though. I mean .. a LOT ..

    And I played Mercenary. And while scope and freedom of Frontier is nice, I dont understand why anyone would want to trade fruits as main gameplay element. I like the mystery and exploration of Mercenary a bit more.

    • Like 1

  5. Posted · Edited by Dr.Sid

    Another Sid here ? Damn .. :-D

     

    Anyway .. tranformation goes like this:

     

    I use 3x3 matrices. I use position (which makes the 4th row usually) outside the matrix, because I use 8 bits for matrices, and more for position.

    So at the beginning I have camera matrix (it's Z pointing to where camera is looking, X goes to camera right, Y to camera up, all is ortonormal - perpenficular to each other and of unity length - that means 7f).

    Then I have object matrix. Same sense as camera matrix. Then there is camera position and object posion, let's say in 16 bits (it's more, but it's not imporant now). Then I have object vertices in 8 bits.

     

    First I get so called model-view matrix. It's combination of transformation from object space to world space and then from world space to camera space. So I multiply inverse matrix of camera with object matrix. Inverse camera matrix is easy to obtain, as the matrix is ortonormal, it's just the matrix flipped around its main diagonal.

     

    But as my matrices are 3x3, this matrix does not contain translation. To get correct translation, I have to basically get relative vector from camera to object (just simple subtraction) and transform it into camera space. This is done by multiplying the relative position vector again with inverse camera matrix.

     

    After that it's simple. Each object vertex is multiplied with model-view matrix and then transformed relative position is added to it. This gives me final position of the vertex in camera space.

     

    Sorry I didn't have time to go through your code so far. I don't understand one thing .. in this demo of yours, you don't even need camera, or perspective to that matter. How is it ?

    • Like 1

  6. Posted

    Well, it's the 21st Century. So why is one writing code on a 6502 ?

    The Atari is based on the 6502 with 1.79MHz , ANTIC, GTIA, POKEY. If you want to have something running on that hardware, you have to accept the limits, that have been given back in the days. Otherwise, it is not the Atari of that time, which blows the cause for doing stuff on that machine. 2 factors have been allowed to add:

    1. more RAM, as the A8 is build for Cartridges

    2. a second POKEY could fit into any Cartridge

     

     

    So what's the cause for doing stuff on a Machine that is not "in the line" of Atari?

    Actually, we have the year 2015. 64 Bit computers, 128GB of RAM, giant graphics cards... Sound without limits...

    You could add such Hardware into an 800 case... it may look 100% Atari...

     

    I agree. I chose Atari 800, as it was popular computer around me when I was a kid. Memory extension is fine. Lot's of people had it back in the day. Most people have them today. No problem.

    I have no problem with the game requiring dics. Again, there were games like that. And everybody has some kind of disc today.

    Supporting different processor, that's something quite different. If it shows the game needs only slight modification to support it, why not. But it's not the goal.

     

    As for faster CPUs, the game for sure should be speed independent, and it will be. This demo is not. Maybe I will release it later with some modifications I have in mind, this is one of them.

  7. Posted

    The divs for transformations are of course factor muls?

    No, they are not. So far I could make any 'trick' working. It's 16/16 to get 8 bits of result. Only trick I do is that I know the result will be less then 1. So the second number will be same or bigger then the first. I roll both numbers so I have top bit used on the bigger number. After that I only taky top bytes and I do 8 step 8/8 division. I only need 8 bits of result, and this gives just that with very small error. The division itself is then the common division with expanded loop.

     

    I tried logaritmic division, and it works, but with bigger error. It's not that much faster though, as I also use rolling the words up into bytes.

     

    I tried to make factors work, but so far I just didn't find any system to put it all into tables.

    • Like 2

  9. Posted · Edited by Dr.Sid

    Some profiling from the most complex scene (ship destruction):

     

    Roughly 7-8 frames per second. There are 4 objects, average 68 vertices, 24 lines, 594 mults, 67 divs per frame. That makes on average bellow 9 mults per vertex, which is some measuring error, it's always at least 9. Also this is only for mults done for vertices, not including mults done per object, but those are lot less important (and I've just closed the damn window).

    As for divisions, if the objects is visible, there are always at least 2 per vertex, and some more when clipping, but when it's not visible, there is none, so I guess the average of 1 per vertex is just about right in this scene.

     

    Time is mostly consumed in:

    Mul: 24.5%

    CLS: 11.6%

    Div: 9%

    Line: 6%

     

    In scenes with less vertices and more lines the times are shifted toward drawing lines.

    • Like 1

  10. Posted

    As for the DMA, there is over 20% speedup possible. Except it requires turning the image completely off, which slightly degrades visual quality :D .

     

    Anyway .. I didn't understand half of the things you guys are talking about, as I'm quite new to Atari programming. I don't even know 800 well, much less other hardware. So please, if you really want something specific from me to try, make it more clear. For example I didn't know until this weekend how you boot real 800 with basic off. Never needed it with emulator.

     

    Even after googling I have no idea what XL14 is, so I just can't react.

     

    Anyway, my goal for the demo and the game is so it runs on real Atari. At the moment it doesnt even require any hardware modification. No stereo, no extended memory, nothing.

    As for the game, I might go for more memory, or at least disc to download stuff during gameplay. In other words .. things which most people have these days.

    Also I have to run it on my Atari, which is totally vanilla XE at the moment, with SDrive. I plan memory extension though, even if with cardridge only at the moment.

     

    I'm not interested in any special and rare hardware at the moment. I think I could modify the demo and the game for cartridge, if there is demand for it. But it's not priority, and as for the game, it's pretty far in the future.

    • Like 3

  11. Posted

    My only thought is that as its scripted what would a game run like under the engine in real time.

     

    I do realise that its released as a proof of concept and NOT a game but how would it perform in real time?

     

    Don't get me wrong, I love new releases be they state of the art, BASIC or other, for me it just proves that there's life in the old dog yet ...But lets remember its released purely under the 'demo' category in every sense..

     

    Well it is all realtime, drawing and animation. Object have preset speed or rotation speed, and their position is computed (and it is actually slightly different every time, it can be seen in the ending scene where the ship turns back toward the planet - it ends up bellow or above the planet depending on exact timing).

     

    Sure .. it's far from a game. There is no AI, no physics, no collisions, no scene streaming (managing of object appearing and disappearing as you move through the world). All these are usually quite cheap though, that is if you do them in simple ways usual on 8 bits. Also most of these is done once per frame, or once per object. So it does not really impact speed that much. Everything which is done once per pixel or once per vertex is final.

    • Like 1

  14. Posted · Edited by Dr.Sid

    Wow, this is really good. Years back when I was really programming the Atari I done most things, but 3D graphic manipulation was 1 of the few things I didn't get round to understanding, it was next on my list until that is circumstances took me away from the Atari. I would love to see the 3D engine source code. Out of curiosity what are the algorythms (or mathematical functions) for calculating the Z co-ordinate.

    I have at the moment recently got round to programming a routine to move text around on a mode 8 screen through various patterns for a demo, but I ain't going to finish that until I finish the current project I'm doing, of which is a text adventure engine, and although I've progressed fairly well, this is still going to take some time to finish.

     

    I'm not sure if I can make it clear for anyone, but I will start with something and then we can focus on anything not clear.

    I use matrices for representing camera and objects rotation (not angles). I multiply object matrix and inverse camera matrix to get so called model-view matrix. That transforms vertex coordinates from object space right into camera space. So transformation of 1 point is just 3 axis vector multiplied with 3x3 matrix.

    After this I do clipping with viewport. I use 90 degrees view angle, so limits of what I can see are simply planes of X=Z, -X=Z, Y=Z and Y=-Z. That simplifies clipping a bit.

    Perspective transformation is also simpler because of 90 degrees view angle, it's just x = X/Z, y = Y/Z.

    • Like 1

  15. Posted

    Well those are not actually commands, but just numbers, as you said. I use macros for them so I can more easily write the code, but SceneReset is just zero, AddObject is 1 followed by object pointer, and so on. So yes, it would be quite simple to load animations from disc. But then cutscenes are not the most important thing in the game. I'm not sure if I will keep this code for the game itself (whatever game it may be).

     

     

    As you have this pseudo-language for controlling the scenes/objects, each command could be assigned a code...

     

    i.e.

    SceneReset=0

    AddObject=1

    SceneWait=2

    ...

    and then you can load new data into a buffer in order to have longer animations.

     

    You would need a jump table for each command to jump to the actual command.

  16. Posted

    Agreed. Anyone played Moonfall on C64 ? (Amiga version was good, but nothing spectacular. C64 version was really one of rare, good games).

     

    Wireframe, no real 3d (just horizontal rotation, up-down + speed....), but so much content, trade, fighting, weather, radar....

    Couldn't stop playing until you owned whole planet :)

     

    Wow .. never heard about Moonfall. Looks very cool and it seem to have lots of features I want to have ! Now where did put that C64 emulator ..

  17. Posted

    As for the sequence .. all the state is in the objects themself, including rotation and speed. For objects I only use local speed, so when I set speed for object and rotation, it will follow curve. All the 'screenplay' language does it 'pokes' speed, rotation, and things into objects, animation engine does the rest.

    There is also option for camera to follow any object, and commands for printing the messages and waiting.

     

    Synchronizing with music is done simply by TV frames. Music runs in VBI (it's RMT player), my song has speed 9 VBIs per tracker line. So if I want to wait let's say 32 track lines, I wait 32x9 VBIs.

     

    The commands for changing object use last added object, or there is command for selecting other object.

    Here is short example right from the start of the animation:

     

    SceneReset
    AddObject Stars2
    SceneWait 16*9

    ;ship enter 16 ---------------------
    AddObject Transport
    SetHeading -30
    SetPos -20,1,0
    SetRotation 0,0,-15
    SetSpeed 0,0,1200

    SceneWait 4*9
    SetRotation 0,0,0
    SceneWait 12*9

    ;ship flyby 48 ---------------------
    SceneReset
    AddObject Stars2
    AddObject Transport
    SetHeading -64
    SetPos -100,0,0
    SetRotation 0,0,-4
    SetSpeed 0,0,1000

    SetCameraPos 0,5,-20
    SetCameraObject Transport
    SceneWait 16*9
    SetRotation 0,0,0
    SceneCls color_ship
    ScenePrint " OK12 to OC1: I have exited hyperspace "
    ScenePrint " and request high parking orbit .. "
    SceneWait 32*9

    Btw. SetRotation sets rotation speed, only way to set which way the object is turned in the beginning is SetHeading.

    • Like 1

  18. Posted

    I did not think much about filling. So far I can't see how it could be fast enough. Even the lines are so so.

    Also filling means backface culling, as you mentioned. Culling itself is not that hard or slow.

    But it means you will either only work with convex objects only (like Elite). But then it will simply look like Elite, cause Braben basically used all possible convex shapes :-) Good thing is you can use convex objects backface culling with wireframe too (again, as Elite does).

     

    Or you can use non-convex objects. Then there is some more things to compute, but again, it's doable, and not that complex, I did it on Amiga. I had all objecst split into convex subobjects, ordered in binary tree where in every node there was plane which divided the object. As you draw, you just detected orientation of the plane, and based on that you decided which subtre to draw first, and which second.

    But it means you will fill polygons over already filled polygons. And speed goes down again.

    Also non-convex with backface culling cannot be easily used with wireframe, as sometimes only part of the edge is visible.

     

    Of course this all affects how you store your models, you need faces to both filling and back-culling .. for wireframe you only need edges.

     

    So at the moment I only plan to work with wires, more Mercenary look then Elite look. Also I think it has it's magic, especially for space kinda game.

    • Like 2

  19. Posted

    Thanks for the support guys, I appreciate it.

     

    Very nice demo. I like Mercenary style wireframe vectors.

    Could you make animation flow independent of CPU speed and animation fluency dependent of CPU speed (Rapidus Accellerator or XL14 users probably would be happiest people on the world :])?

     

    To some extent I could. At the moment however all the animation is just tuned to common atari speed. For the game it's basically a must, but even so, there will be some range of fps I will support. Will think about it.

  20. Posted · Edited by Dr.Sid

    I've made little 3D demo, non programming thread here:

     

    http://atariage.com/forums/topic/237244-rescue-3d-engine-demo

     

    I'd like to discuss programming details here, so it does not offend common users. If you have any question, shoot. I will start by pasting beginning of the discussion from Facebook.

     

    heaven/tqa: are you working with 16bit signed range or with 24bit?

     

    Dr.Sid: Objects are in 8 bits signed, matrices are 8 bits signed. World space is 16 bits (basically object * matrix). This space is used for clipping and projection.
    Object position itself however is in 32 bits (might go down to 24, 32 seems to be overkill), and there is process I call subsizing. 16 bits mostly isn't enough for the objects to be both precise enough when close, and small enough (1 pixel) when far. This subsizing process detects if object is beyond 2 bytes, but still close enough to be bigger then 1 pixel. Then it halves both objects size and distance from camera, until it fits. It looks all the same, but can now be done with 16 bits. This transformation is also useful, as it can make objects appear larger, or smaller.
    heaven/tqa: yeah.... the subsizing looks interesting... my objects are signed 8bit coords... but engine works in 16bit signed.... and rotation matrix is 16bit, too... but it was hard work to get it done on screen. so I am always interesting in how others have solved the problems... https://www.youtube.com/watch?v=HRvsWijVzNU
    Dr.Sid: In my experience 8 bit matrix is enough. That is for rotation only. I don't use matrices extended by position vector, so I only use 3x3 matrix for 3D. And those base vectors are all in -1..1 range. The position itself is added and transformed separately. It is 32 bits first, then subsized to 16, then transformed to world (by inverse camera matrix), which is again 16 (as described above).

     

    heaven/tqa: dont you loose precision?
    Dr.Sid: Of course you do. Question is how much. For purpose of your demo (nice filing !) when you only transform the object, and not the camera, I see no problem at all. The most precision sensitive part is camera matrix. Basically you want the camera to be able to turn just so little, that the image shift by 1 pixel. 8bits in just about that, for low resolution display.
    Also the precision only affects the representation. I mean: are 8 bits enough to describe the precise direction I want my camera to point at ? There is no precision loss during the transformation itself, because you basically multiply 8 bits of vertex by 8 bits of matrix into 16 bits world. No bits lost = no precision lost.

     

     

    • Like 4

  23. Posted

    Well .. that is exactly the part of the code I don't understand at all. I think I understand most of the rest, like the division into 4 shorter lines.

    It's hard to read when combined with self-modifying approach. What kind of algorithm is it ? Do you have some simpler code of the algorithm ?

    The division into 4 lines seems to be the trick behind the speed. On the other hand it produces some minor inacuracies along the line. At the moment corectness of the algorithm is important for my application (still secret, sorry ;-D), but I have to experiment with it a bit.

  25. Posted

    http://atariage.com/forums/topic/211628-fast-line-drawing

     

    Hello Dr. Sid. I am glad to see someone else working on this fast line drawing thing. I also do the table thing. I did not do the 4 direction thing because I want to keep things a little more compact. You never know how much space you need for the rest of your game or graphics program. My approach was to use self-modifying code to change dec/inc instructions to go left or right with the line and always draw top to bottom. Not sure you did this, but I have a table for the low and high address for each row on the screen, mine is geared to a 40 column screen. I had each of my tables start at a top of a new page, so when changing color, you just have to set the high byte. Another trick was to process 2 or 4 points within the loops, but only one process for slope math.

     

    Maybe we can combine the techniques and make something that goes super fast.

     

    For anyone else reading this keep in mind this is not for any specific game.

     

     

     

    Sorry for late reaction. I just didn't notice there is something new here. Anyway ..

     

    I took this Warp4x routine and placed it inside our old test. And it is basically same speed as my best version ! Now I have to really understand, how it works ..

    warp4x.xex

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...