Jump to content
IGNORED

STNICCC2000 port for Lynx


42bs

Recommended Posts

26 minutes ago, Heaven/TQA said:

here is the file. that does not have "indexed" frames and the end frame byte and end of file byte are different to V2. just 1 palette for all. so no palette information inside the data. it is straight forward when you already got a "v2" parser. you can look at "displayFrame" label in the source code and "nPolyDraw". and you need the ST palette setup converted to Lynx but that is easy.

 

SCENE_v1.zip 261.3 kB · 0 downloads SCENE_v1.s 31.8 kB · 0 downloads

I like such:

		move.l	d0,a6
		rept	533
		movem.l	d0-a6,-(sp)
		endr

 

Link to comment
Share on other sites

11 hours ago, Heaven/TQA said:

here is the file. that does not have "indexed" frames and the end frame byte and end of file byte are different to V2. just 1 palette for all. so no palette information inside the data. it is straight forward when you already got a "v2" parser. you can look at "displayFrame" label in the source code and "nPolyDraw". and you need the ST palette setup converted to Lynx but that is easy.

 

SCENE_v1.zip 261.3 kB · 4 downloads SCENE_v1.s 31.8 kB · 3 downloads

Here a first shot. Only one direction yet. Little stuttering while depacking.

 

 

nostalgia.lnx

  • Like 2
Link to comment
Share on other sites

1 hour ago, 42bs said:

Here a first shot. Only one direction yet. Little stuttering while depacking.

 

 

nostalgia.lnx 512.06 kB · 1 download

looks cool. I cached the frame start adresses so actually when going backwards I went back that cache table...

not sure how to do it on Lynx as the file is "streamed" from cart...

 

btw. not sure if the palette conversion is correct? as there are purple colors...

 

here you see how the blitter does not struggle to draw... but the 6502 is hard fighting to feed the blitter... ;)

that's why I think that the Lynx has the best (except display AND the sound) hardware/cpu combo of retro consoles I have touched...

 

 

 

Edited by Heaven/TQA
  • Like 1
Link to comment
Share on other sites

59 minutes ago, Heaven/TQA said:

looks cool. I cached the frame start adresses so actually when going backwards I went back that cache table...

not sure how to do it on Lynx as the file is "streamed" from cart...

 

btw. not sure if the palette conversion is correct? as there are purple colors...

 

here you see how the blitter does not struggle to draw... but the 6502 is hard fighting to feed the blitter... ;)

that's why I think that the Lynx has the best (except display AND the sound) hardware/cpu combo of retro consoles I have touched...

 

 

 

I have now a version with separate frames non-packed. This will allow to load a single frame. Only need to "remember" the stream position (or pre-calc it).

I will surely try.

Link to comment
Share on other sites

22 minutes ago, 42bs said:

I have now a version with separate frames non-packed. This will allow to load a single frame. Only need to "remember" the stream position (or pre-calc it).

I will surely try.

i did the easy way out... I just stored each frame start the adress into a lo/hi table in first run through and then later backwards I just loaded that adresses to the parser...

but when doing Elements demo on Lynx... I remember that the cart is like a SD card.... so you have files... but can you not "seek"? so you simply store that adresses when running first time the animation?

Link to comment
Share on other sites

10 minutes ago, Heaven/TQA said:

i did the easy way out... I just stored each frame start the adress into a lo/hi table in first run through and then later backwards I just loaded that adresses to the parser...

but when doing Elements demo on Lynx... I remember that the cart is like a SD card.... so you have files... but can you not "seek"? so you simply store that adresses when running first time the animation?

You don't have to have a file abstraction. It has 256 blocks. The problem is that selecting a block needs bit banging. And it has not random access. You cannot "just" select a byte. You need first select the block and then read dummy bytes until the wanted byte.

So for the frames, there would be an option to use 220 blocks and each containing two frames to have a rather quick access.

So no large table needed, just a selectBlock(frame/2) + seek(frame & 1).

...

 

Link to comment
Share on other sites

1 minute ago, 42bs said:

You don't have to have a file abstraction. It has 256 blocks. The problem is that selecting a block needs bit banging. And it has not random access. You cannot "just" select a byte. You need first select the block and then read dummy bytes until the wanted byte.

So for the frames, there would be an option to use 220 blocks and each containing two frames to have a rather quick access.

So no large table needed, just a selectBlock(frame/2) + seek(frame & 1).

...

 

can not remember how I loaded the parts of Elements demo... long time :D 

Link to comment
Share on other sites

Felix is slightly faster. Real Suzy must obviously take some more time to draw a sprite. In current implementation I assume that its speed is capped only by required bus access. I'm planing to make a test that will interrupt sprite drawing after n cycles and examine how much of a sprite have been drawn to that point.

 

 

17 hours ago, Heaven/TQA said:

that's why I think that the Lynx has the best (except display AND the sound) hardware/cpu combo of retro consoles I have touched...

Sound is not so bad if you'll use a good tool to compose for it.

 

 

Link to comment
Share on other sites

3 minutes ago, laoo said:

Felix is slightly faster. Real Suzy must obviously take some more time to draw a sprite.

I think the card reading in Felix is a bit quicker compared to the Lynx.

 

BTW: Video is taken (of course) from a real Lynx II.

Edited by 42bs
Link to comment
Share on other sites

Just now, 42bs said:

I think the card reading in Felix is a bit quicker compared to the Lynx.

Hm.. I was trying make it match by adding some artificial wait states, but it's hard match for a long run. It's a matter of a good test program that would read a bunch of blocks and print the timing.

Link to comment
Share on other sites

21 minutes ago, laoo said:

Hm.. I was trying make it match by adding some artificial wait states, but it's hard match for a long run. It's a matter of a good test program that would read a bunch of blocks and print the timing.

Disable drawing the poly in the Nostalgia demo should give a good bench. First run is linear read, all further runs use seek to the respective frame.

  • Like 1
Link to comment
Share on other sites

18 hours ago, Heaven/TQA said:

can not remember how I loaded the parts of Elements demo... long time :D 

Any idea, if Vision by Oxygene uses the same technique like Nostalgia or STNICCC2000. Would be cool to have the Wipeout part also for the Lynx/Jaguar.

Link to comment
Share on other sites

23 hours ago, 42bs said:

For the impatient or w/o hardware or Felix:

 

btw. did anybody ever did a better poly routine than the we use "since back of those days" esp. for the jittering right edges of the sprite? Some did some experiements with feeding some "subpix" value into the sprite hardware to adress that (he found such a possibility in the Handy source code). 

Link to comment
Share on other sites

I think the quickest is the stretched/tilted sprite approach.

And this has its draw-backs.

 

I tried the approach calculating left/right points and draw only horizontal line, but it does not seem to be quicker. At least if you have lots off tiny polygons.

The STNICCC2000 or Nostalgic-O-Demo data set is also a bit "unfair" as likely contains a lot of 3pixel polygons due to the down-sizing.

Link to comment
Share on other sites

6 hours ago, Heaven/TQA said:

btw. did anybody ever did a better poly routine than the we use "since back of those days" esp. for the jittering right edges of the sprite? Some did some experiements with feeding some "subpix" value into the sprite hardware to adress that (he found such a possibility in the Handy source code). 

no, this wont work. unless you split the triangle in left and right. the problem is the slope on left and right side depend on each other, and are quantized

Link to comment
Share on other sites

15 minutes ago, Heaven/TQA said:

Why can Sega Saturn do it with sprites better?

Hmm, serious? Because Sega Saturn came out 5 years later and has a real polygon engine. Where as the triangles of the Lynx are just a "oh we can do this" of the tilting/stretching. It is _not_ a polygon engine!

  • Like 1
Link to comment
Share on other sites

2 hours ago, 42bs said:

Hmm, serious? Because Sega Saturn came out 5 years later and has a real polygon engine. Where as the triangles of the Lynx are just a "oh we can do this" of the tilting/stretching. It is _not_ a polygon engine!

nope. Saturn works with Quad sprites... similar to 3do (need to double check again)... but Saturn is 2x Mega Drive with some Risc side kick ;)

 

 

 

Edited by Heaven/TQA
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...