@Patashu: I gather most of those are Windows solutions, correct? I'm not running Windows, I'm on Ubuntu 13.10, with an nVidea GeForce GTX 670, and the latest Bumblebee drivers.
I've isolated the problem strictly to file I/O. The more I change games, the more likely the recording is going to crash. So I have two choices: Take separate videos of the games I intended to demo, or find a better recorder :P
Edit: Sadly, I'm going to bail on this tonight. I'll probably just take short videos of the games I wanted to demo. It's just not how I hoped to debut this.
Lol... can't follow my own advice. Got Kazam working by switching the encoder. Enjoy, and please let me know what you all think!
http://www.youtube.com/watch?v=mCeFpLMn3sc
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.
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).
Got it, I will work on correcting the buffer extents. I'm using considerably less information to initialize my OpenGL settings than the original OpenGL mode, so perhaps it's time to take more of them into account.
AnS wrote:
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.
Some thoughts on that: I definitely like that idea, since I think it would yield considerably better results, but I can't imagine that would be cheap. You'd have to query the color of over 65k pixels, tally them, and then identify the one with the highest count. That could be done a) in the PPU or b) in the voxel renderer with a one frame delay (e.g. use the current clear color for a frame, and determine if that clear color needs to change next frame.)
I would also like to implement a "click and stick" option, sort of along the lines you proposed, where a user clicks on a color and it determines which palette color was chosen by the user. The thing is though, it's a little harder to determine which "pixel" was clicked on when we're looking at voxels at an arbitrary camera angle. It might need a different interface like a palette selection window or something.
All food for thought. Punkrockguy contacted me about getting the code uploaded as a branch off of the SVN trunk, so I will start working with him on that and keep you updated as to the code's availability.
Some thoughts on that: I definitely like that idea, since I think it would yield considerably better results, but I can't imagine that would be cheap. You'd have to query the color of over 65k pixels, tally them, and then identify the one with the highest count.
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.
Lol... can't follow my own advice. Got Kazam working by switching the encoder. Enjoy, and please let me know what you all think!
http://www.youtube.com/watch?v=mCeFpLMn3sc
Looks pretty neat! Ther eis just one little thing: When you play SMB, you don't see farther than the screen and that is obvious when you moved the "playscreen".
Since the start of the thread I was interested on it, Don't give up :)
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.
OK, I gave it the old college try, but I must be very tired, or I'm missing something. The pertinent portions of my code looks a little like this:
// 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.
}
}
but the clear colors I'm getting in no way correspond to the most prevalent color. I think the problem might be with what I'm passing to FCEUD_GetPalette. Any ideas?
OK, I gave it the old college try, but I must be very tired, or I'm missing something.
I was very tired. It helps not to use a uint8 to hold values that could potentially be higher than 256, like the count of each color per frame. Switched it to a uint16, and everything works great. I'll add it as a third option to the voxel dialog.
Just a quick update, I'm still working on this, although I'm having trouble finding time. My two current stumbling blocks are:
1) Still no mouse control in full screen, and
2) waiting for punkrockguy to create a branch for me to contribute the code on the SVN.
Hope to be able to get this to everyone soon.
OK, I think the code is finally complete as far as I am concerned without people actually testing it and finding problems and/or suggesting new features. I managed to get mouse control working very well in full screen, so all of the controls in windowed mode are available. On top of that, I was able to fix a bug in the SDL code with the zapper crosshairs. They would only update when the trigger was pressed, so you didn't actually know where you were firing. So I got them moving around again. I will PM punkrockguy and hopefully we can get this code out to everyone to test out. Stay tuned.
there are lua opengl bindings. anything lacking with respect to emulation or emulator introspection wouldnt be hard to add to the lua implementation file and would actually be of further use to other people.
Hey there. We're still in the process of getting it folded into the source control. At first it will be a distinct branch, and then it will be migrated into the trunk. Until I or someone else gets around to adding OpenGL support to the DirectDraw version (aka the Windows version), it will remain an SDL only option. That being said, I believe you can compile the SDL version in Windows (someone correct me if I'm wrong), you just have to enable different compiler options.
Long story short, once all the kinks have been ironed out in the original release, I'll see if I can't get it running in Windows without too much hair pulling.
I kind of don't understand this attitude zeromus. I mean, far be it from me to argue with you, but I don't really think the inclusion of this in the windows version would "pollute" the source as you say. The voxel code would still live in its own cpp/hpp files, it's just a matter of providing the address of the DirectDraw surface buffer to OpenGL so that it can render directly to the surface.
The final call is up to you, but I would imagine you'd at least want to see how the source code turns out before making a final judgement call.
Here are some reasons why zeromus may not like the voxel drawing mode to be in the main app and would prefer it to be a separately maintained branch and/or plugin:
-If it is part of the main app that everyone gets, there is an expectation that it not be broken, that it remain polished and up to date and 'not crufty', etc. If it is made entirely by and to the ideals of a separate developer who may not continue working on the project, it may just age and deteriorate.
-It is out of scope/not part of the intended functionality the developers want the program to serve.
-If it has high coupling (is reliant on many implementation details and parts of the source being just-so) requiring it to be supported could slow down refactors and rearchitectures of the code.
This happens in a lot of places, for example many plugins for Notepad++ that are super useful like TextFX, even when they get bundled with Notepad++, they still aren't a core part of Notepad++ because of reasons such as the above.
Patashu, I give you high marks for making complete sense, every one of those reasons is valid and I can't argue against them. That being said, I would be completely fine if the code behind the voxel engine remained in a branch, so that at least anyone who was curious about the effect could have access to it and be able to enjoy it. I just don't see how I could have possibly done this in lua and gotten anywhere near the same level of performance out of it. (That and I just have a much better grasp of C++ over lua.)
Anyway, I submitted the code into a branch that punkrockguy created for me so now, theoretically, he and everyone has access to the code if they would like to sync to that revision. I'll provide more details once I hear back from prg and can confirm that he got everything working.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Unique features are what makes emulators be loved by people.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
If you want to add a third arm to a man, go ahead. That's cool. If you want to give him infra-vision, do it. Want to triple his memory? These all make sense. Don't bolt a fully-automated mini marching-band jukebox to his back. It doesn't belong. If we commit your voxel stuff, then we'll commit the next guy's minesweeper clone?
I looked at the voxel code which was checked into the trunk instead of the branch so that I could judge it. Whatever difference in computational speed between lua and c++ there would be is dwarfed by the relative inefficiency of the opengl approaches used.
Also, you didnt actually put a license on the source code. That's not acceptable for FCEUX; it needs to be one of MIT or zlib or GPL.
I get it. You want to make something cool and contribute. This doesnt cut the mustard. If you do it through lua and discover deficiencies in the communication from FCEUX then we'll address those and youll be performing an actually useful service by encouraging the development of things which _cant_ be done in lua right now, so that in the future they can. If you prove that lua can do opengl visualization, you could open the gateway to some seriously cool stuff.
Well, I'm about as genuinely discouraged about this as I've ever been, so... thanks for that.
No, I'm not going to bother writing this in a language that serves no purpose to any other project. The whole point of this was to write an engine that would be relatively easy to port to other emulators. I've done that. Zeromus, if you want to write it in lua, go nuts, I have zero interest in doing that.
I've got the code properly submitted to the branch, but I think I might just be better off forking the whole project and maintaining it as my own one-off. I appreciate the help and support that many of you provided. I hope that those of you who wished to experience this for yourselves get the chance to do so.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
No, I'm not going to bother writing this in a language that serves no purpose to any other project. The whole point of this was to write an engine that would be relatively easy to port to other emulators.
The main point in writing it in Lua is precisely portability to other emulators. If you had made a lua script, it would immediately be usable in about 15 other emulators that implement the same Lua standard. For example, nearly every emulator in this list
