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.
Write stuff like this in Lua? Major issues I see:
- Performance (this thing pushes nearly 3.5Mpx/s). Yes, Lua is fast, but...
- Getting OpenGL 3D display out of Lua.
one could always ABORT!! and use lua to dump the framebuffer to a socket and do the visualizing in an external tool. I think this would more likely be due to the difficulties of getting GL contexts working in lua from various emulators and platforms. assuming anyone's ever done it even under hospitable circumstances.
anyway, if fceux were hosted in git, you would have already been doing it as a fork because thats the way everyone does everything.
edit -
I just got a iupGL and luaGL demo running in fceux in windows (but I had to mod FCEUX sources a little due to some confusion about whether we're static linking libraries or using dlls. it seems someone decided to change us to using lua DLL, but we're still static linking to some old libraries. thatd need sorting out.)
the luaGL is sort of an old model that doesnt support shader, but does support client arrays and index buffers. should be possible to produce some faster approaches.
maybe someone's made a better lua GL binder, but using openGL is excessively complicated nowadays and I doubt anybody's trying to do anything real cutting edge with it in lua...
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I'm recalling the story with NeXT computers...
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.
It's a new day, and I figured I'd attempt a rational response to Zeromus.
I understand completely that a voxel engine is by no means central to the emulation of the NES, let alone any system. It's a completely "extra-curricular" (for lack of a better expression) feature for an emulator to have, and certainly does not belong in any emulator core.
However, I would also argue that neither should a lua scripting interpreter be considered core or integral to an emulator. Is it cool? Yes. Is it necessary? No. So the only arbiter of what side-projects make it into an emulator are the official maintainers of the emulator itself. And then it becomes a question of how well those side-projects line up with the maintainers' priorities. In this case, a lua interpreter obviously lines up extremely well with Zeromus' priorities, and the voxel engine does not line up at all. That's fine, and I even anticipated that this might be the case.
That being said, the way you (Zeromus) went about expressing that was so insulting to the point of being hurtful. Rather than recognizing the passion that I had for the idea, and recognizing the support that others were giving it, you flat out dismissed it by saying that I didn't go about in the manner that you would have preferred and that "this didn't cut the mustard," an opinion that is not shared by everyone. So you minimized the accomplishment, and added insult to injury by calling the approach I took inefficient.
I never claimed to have come up with the best solution possible, and my hope was that by sharing the code publicly, it could be improved upon by others who were more knowledgeable about how to squeeze more performance out of OpenGL than I. I'm not even going to address the issue of how this feature is in no way suitable for a language meant for scripting as opposed to rendering. No license on the source code? No problem, work with me and we'll slap one on it.
I'm not writing any of this to try and convince you that my work should be as equally included in FCEUX as the lua interpreter. Quite the contrary, I'm very content to maintain it on my own. The reason I'm writing this is for the unlikely chance that it actually causes you to pause and reflect on the way in which you deal with other people, particularly people whose interests and desire to contribute do not necessarily line up precisely with your interests. I doubt that you care, but each post you make creates an impression of who you are. And if I were a person who had not already made the choice to contribute something to your project, I would seriously reconsider whether I wanted to associate with you based on how you've reacted to this. And that next person might have come up with something that you _did_ appreciate. But in all likelihood, you'll simply read this, shrug, and maintain your position, which is your prerogative.
I'm getting off my soapbox now. I chose FCEUX because it already contained the necessary OpenGL support and it was within my ability to write the necessary C++ code for. I wonder if I might have received a warmer reception from the authors of other emulators.
Sorry, you're wrong. Scripting is core and integral to many applications designed to get work done and facilitate creativity, as emulators are. It's so people can do experiments without mucking up the source code and having everyones experiments stomp on each other eventually.
Experiments carry a cost when checked into the source code. They bitrot and create dependencies, increase bloat and build time. They slow down development by leaving hooks in things even if there arent very many hooks.
Of course, some experiments can only be done in the sources and those are what forks are for....
I can't really respond to the rest of this, except to say that I don't have time to figure out how to be nice since it doesnt come naturally to me and I am already booked 16 hours a day for the rest of my life working on things to make people happy. I think I'm being nice when I help you get work done, which I am, to the best of my abilities, whose quantity might be debateable. Thats the only kind of nice I know how to be.
Mustard-cutting and inefficiency are technical evaluations. It's nothing personal.
You might not understand what's going on if you dont have much experience developing software collaboratively. If you're interested in the health of software instead of just jamming your toy in it, youll listen to the people that have invested hundreds of hours of their lives (feebly, perhaps, trying at least) cultivating it, when they tell you ways you too can contribute to its healthy growth. We can't all jam our toys in the same box, eventually it'll bust open. We have some experience judging which toys fit and which toys dont.
Now that I've thought about it more, I'm very interested in the possibilities of blasting framebuffers over TCP to external programs for post-processing. That could be a useful tool and would profit from baking-in to the emulators.
I figure I should probably chime in here. I originally offered ProcyonSJJ a feature branch on the fceux subversion server so I could look over the code and try to help out where I can. I also mentioned that if the voxel engine code was specific to the SDL port (drivers/sdl/*) and if the code was clean I would consider a merge.
I honestly have not had a time to look over the code yet (or even keep up with this topic until just now) so I can't comment on the code itself but I would not at all be opposed to hosting the sdl voxel engine on a feature branch (although to be fair I do not speak on behalf of the entire team).
If anyone wants to check out the SDL fceux-voxel feature, feel free to check it out from the feature branch. I fixed the scons scripts so that you can build it the same way you normally build fceux (just run "scons"). You can check it out with this:
svn checkout svn://svn.code.sf.net/p/fceultra/code/fceu/branches/voxel fceux-voxel
I apologize if a lack of communication on my part escalated any unpleasantness that could have been avoided.
Dont worry, unpleasantness can never be avoided where I am involved.
Clearly not true; you've been a great help to me in the years that I've been working on fceux and I honestly appreciate that. I'm just saying that I think there was a lack of communication on my part that may have escalated things and for that I do apologize.
I wonder if I might have received a warmer reception from the authors of other emulators.
Why?
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.
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?
I would support this in my own personal emulators if the code was done properly. But it seems so simple from what it looks like it does to me that I could code a version in GL3 which removes my concerns about it.
That and I agree with Zeromus. Do this in lua.
You are a bit late for the party. It was already made clear that people in charge wouldn't want to invest into anything not yet made into a complete feature, where the discussion ended.
It is somewhat surprising to see the people who I expected to live to "want it done right do it yourself" philosophy taking passive-resistive positions. What kind of support you are offering, when you say "I might, when it's done"? It is not going to program itself, come work on it. Right now it is merely a concept, but I can assure you there are much more interesting things that can be done, than just extruding a bitmap.
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.
In addition to all of rpahut's comments, you're missing the point. It's not about complexity. It's simply about the concept. Yes, it's ridiculously simple. But no one (to my knowledge, which may be woefully incomplete) has ever done it before. And judging by the general reaction to the YouTube video, this "super simple" concept has garnered a lot of attention, interest, and enthusiasm. Sometimes, it's not about the technical complexity, and merely about someone coming along and implementing an idea for the first time. The first implementation always sucks in comparison to what's ultimately possible, mine is no exception.
mudlord wrote:
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.
Congratulations, you're much smarter than me. You must deserve some kind of award. I'm just a tinkerer, I'm not a perfectionist coder. I found one way that I could implement an idea that I had in my head. If you have a better way to do it, I'd really like to know about it. That's why I started this thread, so that people with better ideas than my own could share them, not so they could be a dick about it.
