Jump to content
IGNORED

STNICCC2000 port for Lynx


42bs

Recommended Posts

2nd one. This one is complete on a 512KB card including all original data (only rez reduced for the Lynx)

It runs in nearly 20FPS despite the mass of polygons that are drawn and overdrawn. But optimizing the scene data is no option in the sense of a "contest" 🙂

 

 

 

Source as usual:

https://github.com/42Bastian/lynx_hacking/tree/master/lniccc2000

 

lniccc2000.lnx

Edited by 42bs
  • Like 12
  • Thanks 1
Link to comment
Share on other sites

6 hours ago, WesleyrpgAust said:

Great looking demo!

 

Shame it can't be used to fix the horrendous framerates of Hard Drivin' and Steel Talons.

Never mix demo mode with game mode 🙂

  • Like 1
Link to comment
Share on other sites

On the other hand,  the demo needs average  52ms to draw a frame from which 28ms is loading from card.

 

But I think 30years ago, we were impressed by most if not all Lynx games (ok, maybe not chess 🙂 )

 

 

Link to comment
Share on other sites

reading back a bit, issue was to squeeze into 512kb and the inexact right side of the triangles.

 

how did you solve it?

> "no option in the sense of a "contest"

so you saved 2 bits? cannot imagine that this already did the job.

 

 

Link to comment
Share on other sites

Posted (edited)
17 minutes ago, sage said:

reading back a bit, issue was to squeeze into 512kb and the inexact right side of the triangles.

 

how did you solve it?

> "no option in the sense of a "contest"

so you saved 2 bits? cannot imagine that this already did the job.

 

 

I guess the reduction from 256x200 => 128x100 produced enough redundancy.

The original data compresses with LZ4 down to 505KB. Leaving 7KB for the "player".

Even TurboPacker would work, but unlz4 was quicker.

Edited by 42bs
Link to comment
Share on other sites

The scan lines are due to the VGA output. I captured it directly from Lynx.

 

Bastion from Prior Art might give a hint what is possible. Though they seem to use direct memory writes instead of Suzy.

 

I have never done a "open world" like or Duke Nukem like 3D engine yet.

Link to comment
Share on other sites

For the Bastion 3D part: Yes, Susy is merely used to clear the frame, effectively it is used to clear the buffer memory only. There is nothing precalculated so it is essentially a line drawing algo and a quick filler (along with quite some 3D math, of course).

Edited by enthusi
Link to comment
Share on other sites

Is the 3D stuff here following the DirectX or the OpenGL conventions when multiplying vectors with matrixes?

 

Thomas Harte wrote a nice multiplicator that used Suzy's multiplication and accumulator in parallell with the CPU preparing for the next calculation. So it was kind of a pipeline. Unfortunately the stuff did not stay orthogonal for very long so I never released anything based on it. But I loved the idea to pipeline stuff and use both chips.

 

It would be nice to have a fast 16 bit library for calculating views into a 3D world.

  • Like 1
Link to comment
Share on other sites

9 minutes ago, karri said:

Is the 3D stuff here following the DirectX or the OpenGL conventions when multiplying vectors with matrixes?

 

It is pre-calculated. The scene1.dat file "just" contains a list of polygons. No 3D calculations.

 

Interleaving math function with other stuff is difficult and I doubt you can make it "general".

Link to comment
Share on other sites

1 hour ago, 42bs said:

Interleaving math function with other stuff is difficult and I doubt you can make it "general".

Yep. Here is the hand interleaved matrix multiplication. But I don't know if there is a flaw somewhere. At least while using it in Stardreamer I did have problems with very strange results after a while.

 

matrix.s.txt

zeropage.s.txt

 

int VertsPoint[] = {
    1,   2,   3
};

int VertsTriangle[] = {
     0,   0,  64,
  -128,   0, -64,
   128,   0, -64
};

int VertsXwing[] = {
     0,   0,  64,
  -128, 128, -64,
   128, 128, -64,
  -128,-128, -64,
   128,-128, -64
};

...
  
    MLoad(&ownship.vbasis_right_x);
    MMultiply(&(object->vbasis_right_x));
    VertexSource = VertsPoint;
    VertexCount = 1;
    VertexTarget = PointBuffer;
    MPerform();

 

3d.h.txt

vbasis.s.txt

Link to comment
Share on other sites

1 hour ago, 42bs said:

Could be a rounding error if you accumulate position over time.

Good point. I planned to do some test cases but unfortunately lost interest...

 

It would be nice to have a 3d library that you could call from C.

 

The value 1 in this system is $4000. So an identity matrix would have all entries as 0 except the diagonal that consists of $4000's.

 

I would like to keep the math so that multiplying a vector with the matrix does not change the length of the vector. It would also be a big plus if the matrix would remain orthogonal concerning the 3 axis.

 

The code is really very good for showing realistic space dust that reacts to climb, roll, speed.

 

 

  • Like 1
Link to comment
Share on other sites

I'm surprised nobody ever explored doing a "fake" 3d games using this technique. Sure the camera would be fixed, but the overall impression would still be great.

 

There is a good example on gameboy color with a toy story racing game I believe.

 

  • Like 2
Link to comment
Share on other sites

Posted (edited)
1 hour ago, karri said:

Good point. I planned to do some test cases but unfortunately lost interest...

 

It would be nice to have a 3d library that you could call from C.

 

The value 1 in this system is $4000. So an identity matrix would have all entries as 0 except the diagonal that consists of $4000's.

 

I would like to keep the math so that multiplying a vector with the matrix does not change the length of the vector. It would also be a big plus if the matrix would remain orthogonal concerning the 3 axis.

 

The code is really very good for showing realistic space dust that reacts to climb, roll, speed.

 

 

Looking at the code I did wonder, why you need 14 bits of FP.

BTW: Doing RMW in Suzy registers feels no good. (asl MATHx).

Edited by 42bs
Link to comment
Share on other sites

2 minutes ago, 42bs said:

Looking at the code I did wonder, why you need 14 bits of FP.

BTW: Doing RMW in Suzy registers feels no good. (asl MATHx).

Yep. The correct way might have been to go with 8 bits after all. It was just that Suzy did have some 16/32 bit stuff in it and I used to be familiar with 3D using fracmul math (Transputers). Fracmul, where an integer was interpreted as a fraction between -1 to 1.

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...