Messages

Great effects, excellent music and sync (as usual from you) and some truly excellent graphics.

Glad you like it and thank you for the nice comment on Pouet, too!

I know this is a very, very late reply but I really enjoyed that Hellfire.
I love the neural pathways idea especially, that looked really cool.

Thanks mate, glad to hear that and hope you are doing fine!
Used the 2 years it took for your reply to work on something new
Please check this out: https://www.pouet.net/prod.php?which=106000

Thanks mates, really nice to hear you like it!

Hey everyone!

Haven't looked into this forum for quite a while and also haven't done much for the last couple of years.
Good to see there's some recent activity happening here and the website also seems to be working much better than last time I checked!

Didn't find a fitting subforum to post this but I managed to get a little demo done for Revision this year.
It's for Pico8, which is coded in Lua, so it's probably quite a bit different from the languages that are popular here.
However, all source code is included, so if anyone is interested, you're welcome to have a look.
You can find the download at Pouet.
Have fun and let me know what you think you think about it!
Cheers.

Hi everyone,
Nice to see you're trying to revitalize this place!

Major update! Online Guest Mode is now working!
Of course, it only works if someone else is online at the same time as you are.

I can create a second guest in another browser.
But there's quite a bit of delay between two moves.
Can you have different angles for the 3d view?
Maybe you can also pick the field in 3d.

The given source code seems to draw a perspective floor (which is basically a rotozoomer with different scaling in every scanline).
But when you draw a pixel, you draw a vertical line instead.
The height of that line is fetched from the texture "HMap" (a greyscale heightmap, white=255=high, black=0=flat).
Because that would create a lot of overdraw, you track the current height of each screen column in "LastY[]" (this means you have to fill the screen bottom to top = front to back).
So if you have already filled a column up to line 100 and your next line goes up to 90, you only have to fill the remaining 10 pixels at the top because the lower part is occluded.

The screen resolution (320x240) and the texture size (256x256) are hardcoded (that's the bitmasking with FF).
u0/u1, v0/v1 are used to fetch a 2x2 set of texels for bilinear filtering ("a" and "b" are the 8bit-subpixel components of x0, y0).

The color of each pixel is the interpolated height "cc" so all lines get a gradient from dark (at the bottom) to bright (at the top).

This:

Code Select Expand

(a << 8) + (a << 6)
is used to avoid a multiply by 320 which doesn't make so much sense since 20 years.

An Amiga effect that I started many years ago, but which was not used in a demo since then.
It is an 18 bit flare effect that I started on Amiga in 2009.

And after only another two years this effect finally made its way into this demo

Maybe a bit late but what the heck...

Code Select Expand

b.SetPixel(x, y, (a.GetPixel((distanceTable2[x][y] + shiftX) % myTexture.Width, (angleTable2[x][y] + shiftY) % myTexture.Height)));
In order of relevance:
Modulo (%) is a division and expensive. You can use bit-masking if your texture-size is a power-of-2 (e.g. use "& 255" if your texture is 256x256 pixels wide).
Try not to call SetPixel for every pixel - if you fill scanlines from left to right, the next pixel is always one dword further.
Try not to call GetPixel for every pixel - with 256x256 textures your texel is at [( v<<8 )+u]
"[ x ][ y ] " reads your memory from top to bottom which makes bad use of the cache.

About the cache:
For every pixel you read, the cache fetches 64 consecutive bytes (in the hope that you want to access the following bytes, too).
But instead you're reading another pixel in the next row (x+1) and the cache reads another 64 bytes.
So when you reach the bottom of your table, there are height*64 bytes in the cache.
When start to read from the next column (y+1), you would fetch data was already read into the cache - but is it still there?
The L1 Cache is 32kB so the height of your table must be smaller than 512 before the cache is full.
But you actually want to keep the cache for your texture reads (which happen in a much more random order).
And since other tasks are also using the cache you can't expect to get much more than half of it.
Of course when L1 fails, there's still L2 and L3 and you'll probably see significant diffiferences when you consume more than a megabyte of cache space.

The more confusing part to me is why 4 samples are taken, and what the tangents and those particular polynomials are for.

If you just look at two adjacent points of the curve, you can't say much about the path in between.
All you can do is to draw a straight line (linear interpolation).
If you take the tangents into account, you know in what direction the path starts at the first point and in what direction it continues at the next point. That's all you need to make it a curve.
In this example the tangents are not explicitly given but simply point to the previous / the next point in the curve (that's why you're always looking at four points).
This simplified type is called catmull rom spline.
The w[] is just polynomial interpolation to make it "round".
Also have a look over here.

it should be faster in fullscreen shouldnt it?

Fullscreen probably creates a swapchain which enables VSync.

I seem to spend a lot of time in the vector [] operator. Plain arrays would surely not make a difference?

Not quite sure. Are you using std::vector<> ?
I'm usually using my own containers which have inlined operators.
Since std::vector is a template, your compiler should be clever enough to decide what to inline (at least in release build).
Alternative:

Code Select Expand


Vector3d* src= untransformedVertices.data();
Vector3d* dst= transformedVertices.data();
auto count= untransformedVertices.size();
while (count--)
{
   *dst++= transform( *src++ );
}


What fps would you expect for this scene?

In 1024x768 I get >200fps on an I7.
Not bad but could be improved.

Since your texture (512x256x32) should be completely cached (on a modern CPU), the performance is probably just a matter of instruction counts.
So if you want to make your code faster, we can have a look into your innerloops!

For a start you can use rdtsc to measure how much time you're spending in your texture mapping innerloop and how much in the rest of your code.

Looks fine!
But it's a little bit disturbing that the startup dialog offers a resolution of 0x0 and also picks it as the default value.
Of course it crashes when you actually use that resolution

Just found my old Voodoo3 on the attic this weekend.
I'll give it a test drive in the next days. Hope it still works.

The bad news are that my dos machine stopped working.
So unfortunately no progress until I find a reasonable replacement.
Ebay people are asking funny prices for their pentiums these days...

I want to do OCS stuff, do you think my software rasterizer could run on that, if its just a few polygons?

If you're planning to do it the traditional way (first render to a 1-byte-per-pixel buffer and convert it into bitplanes):
Sorry, no, definetely not. Or at least not at a resonable resolution or framerate.
You can, however, use the blitter to draw lines (polygon edges) and fill the area in between (flat shading).
The lines don't have subpixel precision, though. So it looks nicer to scan the edges manually.
The more bitplanes you have to fill (more bits are set in your color index), the slower it gets.
So you might want to sort the most-used colors by bit-count

Works fine here and looks cool. Nvidia GTX 970 and Win10 64Bit.

Are you looking for OCS (Amiga 500) or AGA (Amiga 1200) stuff?
For our last two demos (click, click) we used VBCC.
It's a C (not C++) compiler which generates decent code and lets you look at the assembly output.
We maintain make files manually and run the compiler from our favourite C++ IDE.
Unless you're going to write your own disk-loader, you'll also need a bit of an operating system (Workbench) to run your generated exe.

Well I'm still stuck on my @#$%^! rasterizer. i would post about it but I think people would find it boring.

Don't know about the others but I love @#$%^! rasterizers 

Are there any results yet?

Just found my old Voodoo3 on the attic this weekend.
I'll give it a test drive in the next days. Hope it still works.
Also have to dig out Win9x and compatible devtools (probably VC6)...

I'm wondering if I can fix any of our old stuff to run on that thing...