All you are doing is getting pixeldata from the raw video buffer, getting pixel colors for each cube, and then rendering each cube. Sounds super simple to me.
And rendering each cube on its own is criminally inefficient. Modern GL offers much nicer things like instanced/batched rendering, etc. And per pixel lighting.
OK, I gave it the old college try, but I must be very tired, or I'm missing something.
No, it can be very cheap. You see, the pixels are not in RGB, they use indexed colors. So you can just create an arrayColors[256], then every frame you first clear the array, then loop through all 61440 bytes of XBuf (in PAL, in NTSC there will be only 256x224=57344 pixels) and increase the arrayColors[XBuf]++. There, you have the array of weights, findmax and here is your color.
// Find the most frequent color before the rendering loop begins.
// (Assumes arrayColors was filled in on the previous frame.)
maxColorIx = 0;
maxColorCount = arrayColors[0];
for ( paletteIx = 1 ; paletteIx < 256; paletteIx++ )
{
if (maxColorCount < arrayColors[paletteIx])
{
maxColorIx = paletteIx;
maxColorCount = arrayColors[paletteIx];
}
}
// Now blank out the count.
memset (arrayColors, 0, 256*sizeof(short));
// Set the new clear color
uint8 r, g, b;
FCEUD_GetPalette(maxColorIx, &r, &g, &b);
clearcol[0] = (GLfloat)r / 256.0f;
clearcol[1] = (GLfloat)g / 256.0f;
clearcol[2] = (GLfloat)b / 256.0f;
glClearColor(clearColor[0], clearColor[1], clearColor[2], 0.0f);
for ( yloop = 0; yloop < 256; yloop++ )
{
for ( xloop = 0; xloop < 256; xloop++ )
{
arrayColors[Xbuf[yloop*256 + xloop]]++;
// draw voxels, etc.
}
}
I've noticed on the video that you're drawing the whole 256x256 buffer of pixels, so sometimes there's black tiles at the bottom of the screen. You should only draw those scanlines that usual renderer of FCEUX draws, e.g. scanlines 0-239 in PAL and 8-231 in NTSC (in Windows version these numbers are customizable).
The Megaman example indeed shows the big problem with the current method of removing voxels. How about this idea: each frame you pass through the pixels array and find the color which the majority of pixels use, then use it instead of background color. This would probably make Iceman stage (and many other games) look decent.
gtk_widget_set_events(evbox, GDK_POINTER_MOTION_MASK);I mean, use one color as the fill, but remove voxels of both colors.
That's too bad. I hoped the engine could gain some popularity among casual players.
Actually, even they use BG color, just not as a "skybox" fill.
So, I guess most of time you'll need to filter out voxels of two colors: of the BG color and of the predominant color.
BTW, the predominant color is better stored not as some coordinates of a pixel, but as an index of the palette entry (e.g. PALRAM[6]). Of course user should be able to define this index by simply clicking screen (then the program retrieves the pixel at these coordinates and finds out which palette entry the pixel uses at the moment).
This is not easily doable, as it requires a certain code injection in the core (ppu.cpp). Once you successfully implement everything else, I can take the risk of carefully doing this.
Everything is plugged in and working. Though, truth be told, Transparency sucks. I don't know if it's due to the way I set OpenGL or what, but all it seems to do is reduce the quality of the picture. It doesn't do what I hoped it would do, which would be to make the voxels more "crystalline" in appearance. As for wave choices, you can pick Horizontal, Vertical, and both \ and / diagonals. I'm still using my cheesy pre-mapped wave method. Derakon, I'll get circle waves in for v2.
This thing is nearly complete. At the moment my three biggest hurdles are:
1) lack of solid control over polling the mouse, to allow for better camera control.
2) too many hard-coded values for the screen size. I've been doing 100% of my testing in 1024x768 windowed, and haven't tried anything else. I need to start making the code more flexible, and to read the values that are currently being used for screen resolution, etc.
3) Providing a good way for everyone to access the source code.
BTW, AnS, I started to look over the Windows specific code, and I realize that it's using DirectDraw, but not Direct3D, which makes perfect sense. But the lack of a proper 3D interface upon which to implement this means it may forever be an SDL-only feature. My knowledge of D3D has always been poor, and substantially weaker than my knowledge of OpenGL. A Windows solution may only come about through a willing volunteer who can undertake the port.Are you sure you were retrieving the right data?
g_signal_connect(G_OBJECT(evbox), "motion-notify-event", G_CALLBACK(handleMouseMove), NULL);
Experimental thought
For games like Zelda, and others that have a top-down or birds eye view, I was thinking of another way to deal with the 3D effect. I imagine the emulator must know when it is rendering a background object versus a player or enemy sprite. If that is the case, it might be possible to have a secondary 256*256 buffer that serves as a depth buffer. Even if it's just 0 for bg and 1 for fg, that would be enough info to let the renderer know that a fg object should be drawn at a depth closer to the camera, so that it "floats" above the background. Any idea if that's easily doable? Without screwing up the emulation too much, because this is the only feature that could possibly take advantage of it.Wait, are you still using that wrong method of getting background color, or sample means something else?
Not everyone has wide display (and browser set to wide enough), the effect if it isn't is very annoying.
Please unembed that wide picture.
You might not even need the sqrt; I think that removing it would mean that the ripple density would increase as you get further away, though, which is kind of counterintuitive.
// global declaration
#define WAVE_ARRAY_SIZE 24
float wave[] = {0.0f, 3.0f, 6.0f, 8.0f, 9.0f, 9.5f, 10.0f, 9.5f, 9.0f, 8.0f, 6.0f, 3.0f,
0.0f, -3.0f, -6.0f, -8.0f, -9.0f, -9.5f, -10.0f, -9.5f, -9.0f, -8.0f, -6.0f, -3.0f };
// in the render code
z = voxelDistance + (wave[ ( x + Frames ) % WAVE_ARRAY_SIZE ]);
Glad to hear you got the performance issues sorted!