ST-NICCC Competition
category: code [glöplog]
Cool platform, a youtube would be appreciated.
On Sam Coupe 512K I have:
First 998 frames per 21505 vbls (2.32 fps)
Last 802 frames per 16999 vbls (2.35 fps)
First 998 frames per 21505 vbls (2.32 fps)
Last 802 frames per 16999 vbls (2.35 fps)
@Antony: Interesting, any release soon? Are they two split parts? Can they somehow be compressed to fit in 512k?
As you may know, data is divided into 64 KB blocks.
The first 5 blocks (320KB) = 998 frames. It needs additional test of data end.
Next 5 blocks (305KB) = 802 frames. Just for speed test, but the colors from the previous frames are missing.
I didn't try to compress data because it's too slow even with uncompressed data.
I don't like the colors after conversion, 128 colors are not 512.
If the number of colors used is not too great, I can try manual conversion.
Now I have a version that uses external memory for data and displays all 1800 frames,
but for better speed it will be necessary to change blocks from 64KB to 16KB.
The first 5 blocks (320KB) = 998 frames. It needs additional test of data end.
Next 5 blocks (305KB) = 802 frames. Just for speed test, but the colors from the previous frames are missing.
I didn't try to compress data because it's too slow even with uncompressed data.
I don't like the colors after conversion, 128 colors are not 512.
If the number of colors used is not too great, I can try manual conversion.
Now I have a version that uses external memory for data and displays all 1800 frames,
but for better speed it will be necessary to change blocks from 64KB to 16KB.
Could you not dither, to create the "missing" colours ?
@Antony is it fullscreen? A small screen is great as well (I think for the platform). The original data can't be reduced by 2 (or more) since the framerate is slow?
@DanLemon: My polygon routine is ready to draw a polygon with a two-color chessboard,
but the same colors are used because there is only one color for the polygon in the palette.
@Buckethead: Yes, it's full screen. Sam Coupe has a resolution of 256*192 with 16 colors. 8 lines is skipped.
Frame skipping is not easy, because they are sometimes used delta frames.
but the same colors are used because there is only one color for the polygon in the palette.
@Buckethead: Yes, it's full screen. Sam Coupe has a resolution of 256*192 with 16 colors. 8 lines is skipped.
Frame skipping is not easy, because they are sometimes used delta frames.
Ok, I created a new version for Sam Coupe with external memory.
For better speed are the polygon data before start playback converted from block size 64KB to 16KB.
In the first frame I changed 3 colors, all other colors are converted according to one formula.
Speed is now 1800 frames per 29609 vbls (3.04 fps).
Program for copy screen buffers must still be in slow memory.
For better speed are the polygon data before start playback converted from block size 64KB to 16KB.
In the first frame I changed 3 colors, all other colors are converted according to one formula.
Speed is now 1800 frames per 29609 vbls (3.04 fps).
Program for copy screen buffers must still be in slow memory.
Quote:
Frame skipping is not easy, because they are sometimes used delta frames.
My mistake: No delta frames are used.
Only ClearScreen() is skipped, but polygons from new frame fills the entire screen.
Now I don't need CopyScrBuffer() and average speed is now 3.51 fps.
Hm, so the data is just 2D, right? Did anyone attempt to reconstruct the thing in real 3D?
How? As the stream are the projected vertices as stream and no other 3d info stored. If my memory is right I asked Leonard for the 3d data and he might have the Studio Max file but the custom exporter is gone.
It's not like modern video software can't do 2D-to-3D back-projection for camera tracking :)
It would be interesting to reconstruct oldschool 3d scenes, could be possible they do it for real photography. Even a demo tool to guess real 3d data from 2d screen space. But beyond my scope now.
Video from Sam Coupe version:
https://youtu.be/KDe2M824BR8
https://youtu.be/KDe2M824BR8
Excellent! Great that you kept it fullscreen, I couldn't expect it could run that nice. What graphic mode it use?
It use graphic mode 4 (256*192 with 16 colors).
The bottom 8 lines from source are cutted.
The bottom 8 lines from source are cutted.
Cool.
Very cool. I'm impressed by the Sam Coupe. I thought it was a glorified spectrum, I didn't know it was that much glorified!
Gargaj, we reconstructed STNICCC in 3D here: https://www.pouet.net/prod.php?which=87735 — PICO-8 version of STNICCC
Megus: can we get any easily-parseable/formatted version of the data? for, uh, no reason, of course :)
Quote:
Megus: can we get any easily-parseable/formatted version of the data? for, uh, no reason, of course :)
All models are procedurally generated with Javascript code. Do you want to have some exported version in JSON format? I can add such file to the repository
That'd be nice, for now I can only see the original scene1.bin (+ JSON-ified versions), some code that does some kind of 3D stuff, and the final data included in the PICO-8 code, which also seems to be compressed.
Porocyon, I've added the folder "json_models" with all the generated data. I think it should be more or less self-explanatory. The "editor" folder has the browser-based rendering of the whole scene, so you can examine the code there. However, if you have any questions, feel free to ask, I can add some README file to "json_models" folder.
Yes, this looks great, I'm pretty sure I can work with this, thank you!
(won't do something with it right away, I'm a bit busy w/ uni exams atm)
(won't do something with it right away, I'm a bit busy w/ uni exams atm)
hah - I had a pico8 version running too, though it parsed the raw original data (via some editor-only features) instead of repacking it. Fully functional, but I never found time to add the intro part and the music, and never got around to releasing it. Cool to see that it's been superseded already though! ^^