Lol, so it turns out my performance is actually just fine. I'm running Ubuntu on a laptop with the nVidea Optimus technology that shuts down the 3D acceleration to preserve the battery life unless you specifically ask for it. All this time, I forgot to add "optirun" to the command line, so I was not using 3D acceleration. Once I remembered to do that and tested the software, my FPS were much higher. Not always 60, but usually close. Obviously, this code will require 3D acceleration to be any good, but just about everyone who tries this will likely have that, so I'm not too worried. Obviously, it could still be optimized, but it shouldn't be terribly necessary just to get decent performance.
@Derakon: Would love to do a circle if I could figure out the math for that. Horiz/Vert/Diagonal waves are simple arithmetic. Can you think of a good formula to use based on n frames?
@Patashu: Anti-aliasing and fog would be great, I will work on adding that. Tinting the Ambient light is a great idea, I will work on adding that too. And like Derakon confirmed, I am using Display Lists for each cube (I took out the backface... seemed kind of pointless.)
Yeah, looking good. Now try messing around with defining ambient, diffuse and specular lighting separately. You could even have the light source(s) such as the 'sun' slowly rotate, have acceleration/momentum or respond to player input in some way.
That's a great idea, I never thought of that. I will have to come up with some way to incorporate that.
I added the wave effect and it's pretty funny, albeit a little disorienting. If I a) had a YouTube account and b) knew how to record from my own screen, I'd post a video of it running, but neither case is true for me. I should work on correcting that.
This is definitely coming rapidly out of the "proof of concept" phase. As far as my previously mentioned plans go:
1) I tried to add a g_signal_connect on "motion-notify-event", but it will only read the mouse when a button is held down for some reason :( I was hoping it would work whether I press the button or not. Definitely a discussion to have with punkrockguy on the IRC.
2) I'm pretty happy with the voxels having more depth than width and height. It heightens the 3-D effect. But I'll still try to make it user definable.
3) Like I said, got the waves going. Pretty funny to watch. I'll find a way to make that user configurable as well.
4) I tried replacing the voxels with spheres using glutSolidSphere, but that was kind of a disaster. Slowed things way down, and the visual effect wasn't even that great. So that idea is out.
Once I get the code considerably cleaned up, I'd like to get this up somewhere public so that you can all try it out for yourselves. I'll try to meet up with punkrockguy over the weekend and set something up for everyone.
So, adding normals to your surfaces sure goes a long way to help lighting out :) I had the lighting all right, I just didn't set the normals on any of my surfaces. Truth be told, for some reason I thought they were calculated automatically, but I have no idea why I thought that...
Still not all the way done messing with lighting, but I consider this is a huge step of progress:
Arrange all displayed pixels by their color
for color in colors:
vertArray = []
for pixel in pixels of that color:
pixelVerts = generate vertices for a voxel at pixel's position
append pixelVerts to vertArray
glColor3fv(color)
glDrawElements(GL_TRIANGLES, number of pixels * 12, GL_UNSIGNED_INT (probably), 0)
That's a really interesting idea, I definitely see how it would generate some savings. I wonder, however, if the savings gained would be lost in the process of sweeping through a 256*256 buffer several times in search of particular colors. Perhaps the vertArray should be a two dimensional array, one array for each color, and the whole buffer gets processed once, dropping vertices into each "paint bucket" so to speak as unique colors are encountered. Definitely something to consider.
Edit: Nevermind, I see what you mean by "Arrange all displayed pixels by their color" now. That would essentially sweep through the buffer once and organize a list of all pixels that correspond to each color, then I build a vertArray from those lists, effectively accomplishing the same thing.
Is your current drawing system doing a colored quad (or cube, or whatever) for each pixel in the original display? That's probably going to be pretty slow even when compiled into a display list. My OpenGL is rusty and outdated and I've never had to push performance, but I'm pretty sure there's some mechanism for "do this operation once for each point in this provided array". Then you'd just compile a set of arrays, one per color, and tell OpenGL to draw one square (or cube, or whatever) per vertex in each array.
You're correct about my current implementation. I have considered doing edge detection, and only rendering the sides if they bump up against the background color. That would enable me to render only a front facing square instead of all six sides if it's surrounded on four sides by a non-background colored pixel. Should result in some significant savings. Although, it may look weird if/when I add some translucency to the voxels.
"punkrockguy318 wrote:
Sounds pretty cool and I wish you the best of luck with this! If I can help out at all (some of the source code is rather.. erm... mystical? heh) let me know
Thanks so much punkrockguy, I really appreciate the support. I may just drop by on the IRC if I have some time over the weekend. Some replies:
1) Thanks so much for the info about scons, I had a feeling it was something like that. That will help me out quite a bit.
2) I'm using the absolute mouse coordinates in relation to (to be precise) the GTK window (since I'm not yet running this full screen. I'm leaving a terminal open to watch the debug output.) So GTKMouseData[0] and GTKMouseData[1] are what I'm currently using.
3) I would be more than happy to host this publicly it's just that,
_a) I've never hosted code before, so if I could get your help walking me through the process, I'd be grateful. But more importantly...
_b) ...this thing is a mess right now, I've hacked up stuff terribly just to hijack existing methods with no real respect paid to user settings, etc. Ultimately, when I'm done with the proof of concept phase, I'll take some time to clean it all up, give it a new home, and hopefully add some configuration settings that will distinguish this behavior as a new feature instead of hijacking an existing one.
I'm at (real world) work right now, so I only work on this at night when I'm home. My current hurdle is still the lighting, and I won't be moving on to the rest of this list until I get that sorted out, but among the finishing touches I have planned, I will be trying to:
1) Expand the mouse control over the camera. Right now, it can simply move around to the left, right, up and down (it automatically zooms in/out relative to how close to the edge of the screen it gets.) I hope to add manual zooming as well, and possibly absolute positioning and roll (not sure why anyone would roll the camera, but just for fun), and also possibly the ability to swing the camera all the way around to the back side of the rendering (to see the game in reverse).
2) Add the ability to play with the size and spacing of the voxels. Right now, they are all 2x2 cubes with 0 space between them. Users should ultimately have the ability to add some space between the voxels if they wish, and fatten them up in any of the three dimensions. Fattening them up along Z (depth) should be the most interesting to play with, since that will go a long way to making the whole scene look more three dimensional.
3) Have some fun playing with the Z (depth) position of the voxels, incorporating waves into the scene while the game is playing (so it looks like ripples are crossing the scene. Could be vertical, horizontal, or diagonal. If I'm really feeling ambitious, I'll try circular out from the center...
4) Add the ability to swap the voxels for little spheres (using the glutSolidSphere method instead of my display list).
More to come, hopefully tonight. Thanks again for all the responses!
@Patashu: No, I haven't, thanks very much, I'll take a look!
Fixed the mouse issue, gave me a lot more choices to play with. Some more progress (dunno how long these tinypic links last for...):
A bit of progress. Not quite the quality I would have hoped for, these images never really do seem to look 3D, but that's because I have no clue what I'm doing when it comes to lighting, so everything looks matte. I need to find someone who really understand basic OpenGL lighting principles very well.
Problems I'm having so far:
1) Obviously, I have a clipping issue in the back corner there, need to expand the frustum,
2) The lighting issue I mentioned earlier, can't really make it look 3D until I can make the edges reflect differently.
3) I'm only able to read the mouse with Zapper games, and only when I press click (hence the Duck Hunt shot). I need to poll the mouse continuously even in non-Zapper games.
4) Performance. Depending on how many voxels get drawn, I'm going anywhere from 10 FPS to 53. Plus, the image quality isn't even all that great... lots of jaggies.
Again I think if I consulted with someone who was stronger with OpenGL, I'd be able to resolve that. Any takers?
No, no, it was entirely my fault, I was relying on the wrong values (see the edit above). I was double checking and triple checking my code to make sure that I was doing it on every update of the mouse, just didn't realize that the SDL values are only useful in fullscreen mode.
I hit another stumbling block tonight. I am trying to tie the camera movement to the mouse. I see where the line
t = SDL_GetMouseState (&x, &y);
is called in sdl/input.cpp, and I tried tapping into it, but I could only ever get x and y updated as soon as the application started, and never again, no matter how much I moved the mouse around. Yet when I tried out Duck Hunt, it's clearly registering the position of the mouse cuz I can shoot the ducks. All I tried doing was passing the value of x and y to another method after SDL_GetMouseState is called and use those values, but they never change. Is there something that I'm missing? Thanks.
I realized my own problem. I'm running in a window, so I'm forced to rely on the GTK results, not the SDL results. I was going nuts...
You mean the scons script doesn't include -lGLU in OpenGL case and you need something from that library?
Exactly. It does link in GL, but it does not automatically link in GLU, and I'd like to instruct scons to include it rather than using my own bash script.
Thank you both for your replies, a couple of responses:
@Ilari: Thanks for the explanation about the preprocessor, I appreciate it. However, are you aware of how I can instruct scons to include -lGLU in the list of libraries to link against? I had assumed that the OPENGL section of scons was also responsible for including -lGL, but I could not see how that was being enforced.
@AnS: Presumably when I am finished, whatever code I am writing will be portable enough to employ under any platform. That's the nice thing about OpenGL, it should be the same everywhere. I'm merely more comfortable (for now) developing the initial phase of my experiment in linux. Once I get closer to a final product, I will worry about getting it running elsewhere (or ask for assistance in porting). Thanks so much for providing me with the information about the background color. I suspected that the NES might have such a concept, but I didn't know enough about the architecture to know where it might be held.
Hello. I'm in the process of working on something experimental, and I wanted to share some of it while asking for assistance. Essentially, I am writing a voxel engine to be incorporated into the OpenGL renderer of FCEUX. It's an expansion of an idea that I had a while back when I considered doing something similar in MAME (see this thread in MAMEWorld). I found trying to demystify MAME's renderer a little too daunting, but I recently resurrected the idea and have made a fair bit of progress with FCEUX. It also only really works well with games that have a single solid color for a background (e.g. black for older arcade games, the blue sky in Super Mario Bros.) The renderer takes the color in the upper left corner and treats that as the clear color while at the same time ignoring any pixel in the image buffer composed of that color (no voxel).
I have a couple of questions:
1) I'm developing within the SDL version (linux), but I'm not very familiar with scons. I see the whole bit about checking for OPENGL support and adding -DOPENGL to the CCFLAGS. Is there anyway to enforce the addition of -lGLU to the LIBS? Cuz right now I made my own script to link the resulting .o files against -lGLU, but there's got to be a way to have it work with scons.
2) Is anyone here fairly familiar with OpenGL? My lighting isn't working the way I had hoped (I think it has to do with my failure to switch matrix modes from MODELVIEW to PROJECTION, but I don't have enough experience with that. Also, my FPS is pretty poor, even though I'm using a Display List to render the voxels.
3) Would anyone on the official development team have any interest in supporting this concept and/or accepting the final result into the official source code?
4) Does the FCEUX using community at large have any interest in this project?
Thanks very much for your time and assistance.
Procyon
P.S. I'll get some screenshots up as soon as I have some decent looking to share. Right now it just looks like blobs of blocks, and it's not very impressive. I want to attach the mouse to the movement of the camera so you can see more impressive angles.
Problems I'm having so far:
1) Obviously, I have a clipping issue in the back corner there, need to expand the frustum,
2) The lighting issue I mentioned earlier, can't really make it look 3D until I can make the edges reflect differently.
3) I'm only able to read the mouse with Zapper games, and only when I press click (hence the Duck Hunt shot). I need to poll the mouse continuously even in non-Zapper games.
4) Performance. Depending on how many voxels get drawn, I'm going anywhere from 10 FPS to 53. Plus, the image quality isn't even all that great... lots of jaggies.
Again I think if I consulted with someone who was stronger with OpenGL, I'd be able to resolve that. Any takers?
