Luchsenstein 3D

[+BitJag]

A little late to this discussion, but it was incredible to play something like this for the Lynx. If this is every released in a more complete state (sorry for the general term...) I will buy two copies. Just so my other Lynx isn't lonely of course. Awesome work!

Edited September 26, 2014 by lachoneus

[mvirtuale]

The GAME is very nice.
the last enemy always kill me.
hint:
Option 2: Map

[johannesmutlu]

Well the name luchtenstein can be confusing, but it does have a reference to a germen word, i believe castle?, but also to avoid copyright lawsuit from the original wolf 3d owner, wich also explaines why this version is incomplete, BUT that doesn't mean it's bad, in fact, this is an incredible achiefment, concidering the limitations of the lynx and the fact that the lynx dates back to the late 1980's, this game pushes the lynx limitations to new barriers, it can be compared with the snes version in that it will make you feel as having a portible snes in your hand, this game is a must have.

[Android78]

Hi Guys. I just came across this thread and it sparked my interest since I made a similar engine for the lynx back in my uni days (some 15 or so years ago). It wasn't nearly as polished (or finished) as luchsenstein, but the basics were there.

I also used the horizontal format, but realized while I was looking at the graphics engine that it could have been much faster vertically, but would be terrible to play that way. The reason is the way suzy works with sprites, rendering them in rows, not columns. When combining the tilt and stretch parameters (tilt is how much right or left you want the next line to start being drawn from the previous and stretch is how much to scale the next line from the previous), this makes creating perspective vertically relatively simple and horizontal quite difficult (or will at least use more mikey time). The easiest way would be to setup each wall as a sprite with correct v size (which would actually be horizontal), starting h size, tilt and stretch values and draw using painters algorithm. This would cause some overdraw, but would free up mickey. The problem with this method as opposed to ray casting is that the horizontal scaling wont be accurate, but this should be pretty minimal (there is some mention in the documentation that the vertical stretching can be changed per line, but this isn't in the sprite control block, so no sure how that is supposed to work).

The way it works is, if you have the sprite data as follows:

99119911
22992299
99339933
44994499
99559955
66996699
99779977
88998899 

... and a tilt of -1 (0xFEFF) and stretch of 2 (0x0200) then it would be rendered as (use your imagination... the '.'s are undrawn on screen pixels):

........99119911........
.......2299922299.......
......999333999333......
.....44499994444999.....
....9999555599995555....
...666699999666669999...
..99999777779999977777..
.8888899999988888899999. 

You can see how this would be good for creating a perspective view. I think this is why John Carmack suggested his engine would have held the system vertically.

It's a shame that the system didn't have a way to swap the rendering to column, rather than row as we would have then had possibility of some really cool games.

 

There is probably a way to combine ray casting and the suzy scaling. I think my engine I had every wall divided up into columns and had SCB for each ray that would point to the sprite data with whichever wall column it hit and set the scale correctly for the distance. I knew it wasn't the most efficient at the time, but I had 6 months to get it done as well as all my other uni assignments.

 

Anyway... glad to see that there are still people out there like me who are curious about this ancient hardware. With all the advancements, I still don't get as excited by the latest iphone/PSV/3DS as I did when I soldered 8 uv erasable flash chips to a board and soldered that to the connector from a cartridge to get my first program running on the lynx... those were the days!

[sage]

You can see how this would be good for creating a perspective view. I think this is why John Carmack suggested his engine would have held the system vertically.

It's a shame that the system didn't have a way to swap the rendering to column, rather than row as we would have then had possibility of some really cool games.

 

There is probably a way to combine ray casting and the suzy scaling. I think my engine I had every wall divided up into columns and had SCB for each ray that would point to the sprite data with whichever wall column it hit and set the scale correctly for the distance. I knew it wasn't the most efficient at the time, but I had 6 months to get it done as well as all my other uni assignments.

 

like this? lynxmaze_22.zip

 

Main issue is to get the scalings right, and this is hard because you have only a few bits, Assuming you want to have the textures limited to 16x16 pix.

Special care has to be done for textures going outside of the screen. Yes they are clipped automatically, but if they get to large, things tend to explode

 

yeah, and dont forget that the emulation not accurate here. things might look o.k. in emulation but not on hardware or vice versa.

[obschan]

Wow that's actually an awesome achievement using this approach.

[Lynxpro]

Hi Guys. I just came across this thread and it sparked my interest since I made a similar engine for the lynx back in my uni days (some 15 or so years ago). It wasn't nearly as polished (or finished) as luchsenstein, but the basics were there.

I also used the horizontal format, but realized while I was looking at the graphics engine that it could have been much faster vertically, but would be terrible to play that way. The reason is the way suzy works with sprites, rendering them in rows, not columns. When combining the tilt and stretch parameters (tilt is how much right or left you want the next line to start being drawn from the previous and stretch is how much to scale the next line from the previous), this makes creating perspective vertically relatively simple and horizontal quite difficult (or will at least use more mikey time). The easiest way would be to setup each wall as a sprite with correct v size (which would actually be horizontal), starting h size, tilt and stretch values and draw using painters algorithm. This would cause some overdraw, but would free up mickey. The problem with this method as opposed to ray casting is that the horizontal scaling wont be accurate, but this should be pretty minimal (there is some mention in the documentation that the vertical stretching can be changed per line, but this isn't in the sprite control block, so no sure how that is supposed to work).

The way it works is, if you have the sprite data as follows:

99119911
22992299
99339933
44994499
99559955
66996699
99779977
88998899 

... and a tilt of -1 (0xFEFF) and stretch of 2 (0x0200) then it would be rendered as (use your imagination... the '.'s are undrawn on screen pixels):

........99119911........
.......2299922299.......
......999333999333......
.....44499994444999.....
....9999555599995555....
...666699999666669999...
..99999777779999977777..
.8888899999988888899999. 

You can see how this would be good for creating a perspective view. I think this is why John Carmack suggested his engine would have held the system vertically.

It's a shame that the system didn't have a way to swap the rendering to column, rather than row as we would have then had possibility of some really cool games.

 

There is probably a way to combine ray casting and the suzy scaling. I think my engine I had every wall divided up into columns and had SCB for each ray that would point to the sprite data with whichever wall column it hit and set the scale correctly for the distance. I knew it wasn't the most efficient at the time, but I had 6 months to get it done as well as all my other uni assignments.

 

Anyway... glad to see that there are still people out there like me who are curious about this ancient hardware. With all the advancements, I still don't get as excited by the latest iphone/PSV/3DS as I did when I soldered 8 uv erasable flash chips to a board and soldered that to the connector from a cartridge to get my first program running on the lynx... those were the days!

 

 

What games did you do on the Lynx?

[apr2499]

So exactly how do you get this to play on an actual Lynx? I have the Mateos flashcart and eeprom carts. Generally speaking, the file size has to be exactly 128kb, 256kb, or 512kb to work on the real hardware. Are you padding the file with zero's to get this to work on a lynx? if so, how are you doing this?

 

I really want to give this game (and other homebrews) a try.

 

Thanks!

[Twoface2]

So exactly how do you get this to play on an actual Lynx? I have the Mateos flashcart and eeprom carts. Generally speaking, the file size has to be exactly 128kb, 256kb, or 512kb to work on the real hardware. Are you padding the file with zero's to get this to work on a lynx? if so, how are you doing this?

 

I really want to give this game (and other homebrews) a try.

 

Thanks!

 

Look into Mateos Flashcard thread. On the last page you'll find it.

[Rick Dangerous]

This will be the first thing I load up on the RetroHQ SD Cart tonight!!!

[Rick Dangerous]

AWESOME GAME!! I can't believe how good this looks on the LYNX. Looks better than the SNES version.

 

Only needs a "run" button