pouët.net

Ah, ignore that, I read the code wrong!

For me it looks, as if you read the colors of the palette backwards.

Fixed thanks!

Cool.

Fixed also the gaps between the polygon edges.

But the resolution seems to be 255x199, not 256x200 (there is a 1px wide black line on the right and bottom edges).

Can it be?

Are you indexing from 0 or 1?

I consider the whole STNICCC screen from Leonard as -lame-.
The whole thing can be done in realtime with only little framedrops.
Just take a look at TCB's Flashback 3D-intro. (ok, they precalc the drawing order, but it's a big big difference to the STNICCC screen, which is just a lame polygon stream. Totally overrated!

Max x value it's 255, to avoid overdrawn you don't have to write the last pixel of a scanline... so yes, I also have a vertical and horizontal line at the right and bottom edge.

Jaguar emulator it's not very accurate... By the way, I'm the last 11:59:56!!!!!!
100% C code, 8 bits image drawn and erased pixel by pixel (no int32_t * were used) , no GPU, no Blitter, no optimisation.

1800 frame / 720 sec = 2,5 fps :)

J am sure Jaguar can kick some but but looks good. Keep em coming!

Me looking for another platform.

From the description:


Don't know quite how to interpret that, can the individual polygons be non-convex, or just the resulting, overlapped scene?

Scenes are build not only by Tris or quads... can be up to 15 vertices. Last vertice connects again to first.

Yeah, but I meant if these individual polygons are convex? I mean, as soon as you move beyond 3 vertices in theory you can create a polygon that is no longer convex.

So, in essence:

Do my renderer need to be able to handle cases like the ones on the right?

IIRC I've only found a few poligons that some times when you do something like:
width = right_edge - left_edge; you got a negative value. But you'll never find a polygon with two spans on the same scan line.

Great, yeah, that's what I wanted to know, I'm thinking about a span-based poly-filler, so having to deal with arbitrary number of spans on a scanline would have been a pain in the ass.

You can ignore the case of non-convex polygons. So a regular span-filler with 1 span per line is fine.

Atari Jaguar V1.0, slow as hell, now it runs a bit slower because I've added music. Have a try in an emulator because it will run faster XD.
http://swapd0.blogspot.com/p/st-niccc.html

Just to clarify: is it okay to change the data format (as e.g. the web version did) or are ports expected to use the original data file?

I love how the website still says "grench".

Altering data? Hmmm... why not... or how would you do the C64 version then? ;)

Or an Atari 8bit version that doesn't require gfx- and memoryexpansions ;)

Altering the data is fine for me. I know this opens up possibilities no one really wants, like pure anim players. But I dont want to prohibit platforms, e.g. with less then 640 KB memory. And such a "dont change the data" rule is anyway close to impossible to monitor.

@Kabuto: Is there Mega Drive joining in?

@Britelite

Hehe... ;) but Atari 8bit without VBXE means still standard RAM expansion up to 1MB.

In the same way that C64 means a C64 with a standard 16MB REU.