Messages

1

Game Coding / Re: Online Chess Project (I'm Back!)

« on: April 19, 2018 »

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.

2

General coding questions / Re: voxel waves

« on: April 06, 2018 »

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]

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

3

Challenges & Competitions / Re: [Amiga 30th Anniversary] Flare Mixer

« on: November 28, 2017 »

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

4

C / C++ /C# / Re: [C#/GDI+] Xor Texture Tunnel (aka Fake 3D)

« on: May 10, 2017 »

Maybe a bit late but what the heck...

Code: [Select]

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.

5

C / C++ /C# / Re: Help with understanding demo source

« on: July 07, 2016 »

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.

6

C / C++ /C# / Re: [C++] [software rasterizer] Triangle rasterizer gaps

« on: July 02, 2016 »

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]

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


7

C / C++ /C# / Re: [C++] [software rasterizer] Triangle rasterizer gaps

« on: June 28, 2016 »

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.

8

C / C++ /C# / Re: [C++] [software rasterizer] Triangle rasterizer gaps

« on: June 20, 2016 »

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

9

Projects / Re: Any Productions here that will work with a PII/DX6.1/W9x/Voodoo3 ?

« on: May 19, 2016 »

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...

10

General coding questions / Re: Amiga coding

« on: May 18, 2016 »

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

11

Purebasic / Re: Demo Test

« on: May 16, 2016 »

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

12

General coding questions / Re: Amiga coding

« on: May 16, 2016 »

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.

13

General chat / Re: What happened to DBF that not much is going on here?

« on: February 11, 2016 »

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 

14

Projects / Re: Any Productions here that will work with a PII/DX6.1/W9x/Voodoo3 ?

« on: February 08, 2016 »

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)...

15

Projects / Re: Any Productions here that will work with a PII/DX6.1/W9x/Voodoo3 ?

« on: November 18, 2015 »

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

16

Projects / Re: Any Productions here that will work with a PII/DX6.1/W9x/Voodoo3 ?

« on: November 18, 2015 »

It runs lots of old Dos-Software, sometimes native dos-software work under win98s-dos-window but not under plain dos anymore, because the machine is quite fast (TP-Bug)

There is a tool called "PatchCRT" which fixes this bug (a problem in the Borland runtime lib).
To make this work for demos (and especially intros) you usually have to uncompress the exe first (using "unp").
The bug does not appear when I downclock my Celeron to 200MHz.

On Windows a lot of demos were using DirectX8 (because the API got much nicer).
And I'm pretty sure you can install DX8 under Win98.

17

Projects / Re: Any Productions here that will work with a PII/DX6.1/W9x/Voodoo3 ?

« on: November 17, 2015 »

I'm still running my old Celeron 450MHz but I'm only using it for DOS demos.
Mainly because the mainboard still has an ISA slot to hold my Gravis Ultrasound.
Maybe that's an option, too.

I guess the Voodoo3 still has the 256x256 pixel texture size limitation?
That will probably rule out most accelerated demos...

18

Challenges & Competitions / Re: Amiga 30th Anniversary Compo - [Vote-Off]

« on: October 20, 2015 »

Guys, you made really cool stuff - all of you!
Additional props to Noname for doing an Amiga demo while doing an Amiga demo!
And fuckings to me for not doing anything (again)

19

Challenges & Competitions / Re: [Amiga 30th Anniversary] Flare Mixer

« on: October 01, 2015 »

Great one, Noname!
And two thumbs up for submitting an actual Amiga production to the Amiga compo!
At first I thought it's missing some kind of overlay (a logo, scroller, ...) but it would just distract from the effect and somehow degrade it to a "background effect". So everything is perfect.
Also great choice of music - one simply can't get more "Amiga" than Virgill

20

C / C++ /C# / Re: Code Design - splitted project parts

« on: July 03, 2015 »

in a new file data.h:
static long bufferColors[360 * 256];

Then add this to every file where you will use it

#include "data.h"

This way every cpp-file which includes data.h will create its own buffer.
But I guess what Vain asked for is a single shared buffered like this:

Code: [Select]

// mybuffer.cpp
long buffer[360*256];


Code: [Select]

// mybuffer.h
#pragma once
extern long buffer[320*256];


Code: [Select]

// mycode1.cpp
#include "mybuffer.h"


Code: [Select]

// mycode2.cpp
#include "mybuffer.h"

This way mycode1 & mycode2 will work on the same "buffer" from mybuffer.cpp.