Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

272 Neutral

About Matt328

  • Rank
  1. Matt328

    Lua with CML

    I got this figured out, I was really close, but missing the signature for a function pointer to member is different than a function pointer to a free function. .addFunction("__add", (Vector3&(Vector3::*)(const Vector3&))&Vector3::operator+=) I had * instead of Vector3::* in the middle of the function pointer type.
  2. Matt328

    Lua with CML

    That is what I hve been trying but poking around in the dark at the end of a very long day trying to guess the function signature had been less than effective. Even when I use auto, the compiler can't figure it out I guess because there are multiple overrides of the operator+= function. I think that is why .addFunction is complaining and making me explicitly cast to one of them. I've also tried using decltype to determine the signature, but with the same results. I was also unable to get operator[] to work and I now realize for the same reason. I am able to define a helper struct and delegate to the original object but I'd rather not have to do that especially if it is as trivial as figuring out what the compiler thinks the function signatures are. I'm using clang with C++14 support if that helps.
  3. I'm having trouble binding pretty much any classes from CML (configurable math library) to Lua. Due to them being such a tangled mess of templates and macros, I can't seem to find the function signatures for the overloaded operator functions.  I'm trying to use LuaBridge right now to register the cml::vector3f::operator+= function, and since there are so many overloads, I think I have to cast the address of the function to the function signature I want it to bind.  Currently I'm trying:  .addFunction("__add", (Vector3& (*)(const Vector3&))&Vector3::operator+=) (I have Vector3 typedef'ed to cml::vector3f) but that produces: Address of overloaded function 'operator+=' does not match required type 'cml::vector<float, cml::fixed<3, -1> > &(const cml::vector<float, cml::fixed<3, -1> > &)' I'm just about ready to punt on scripting altogether and just do everything in C++.
  4. Matt328


    This was originally going to be a reply to this thread, but I think it kinda took on a life of its own. Usually I keep my journal posts technical, but I guess some philosophical musings here and there are good for the creative process. This was partly inspired by something a friend of mine nonchalantly said when the subject of mortality came up: "I have no intentions of leaving this world when this body dies." Everyone else looked at him like he was nuts, but I was on the same page, "Neither do I." Regarding the question in the poll in the post, the whole man in the box vs the man on the stage thing is a problem that needs to be solved before I can vote yes. Here's how I see this potentially playing out. Initially to avoid this problem, more and more of our biological brains could be replaced with computer chips until eventually the entire brain is replaced. Hopefully this would work since the rest of my scenario kinda hinges on that. Imagine how fast we could write programs and run simulations without the whole using a keyboard for input, or even having to go through the trouble of translating thought into code. I'd imagine with this ability we could put our collective minds together and make faster and faster computer brains, and soon, a technological singularity would emerge. At that point, almost anything is possible, nanobots to keep our biological bodies alive forever, or leaving them behind and creating such a computer that could house millions of consciousnesses. From this point on, my imagination kicks in pretty hardcore. Due to the inherently violent nature of human beings, I probably wouldn't want to be around when they eventually destroy themselves. I would probably create some sort of vehicle capable of wandering the galaxy, and would probably fashion it after either the Enterprise or the Tardis, I'm still undecided on this point. One could fashion some sort of transporter/replicator type device to synthesize a biological body, and given that we now have brains that can think and infinite speed, could probably find a way to transfer my consciousness back and forth between biological bodies and computers. Pretty appealing, wandering the universe, living lifetime after lifetime in biological bodies, simulating even more inside a computer. Time travel wouldn't even be out of the question. Boredom and stagnation would be your only threat to survival. I imagine though, whatever would be left of humans, and any other intelligence that may emerge in the universe would provide sufficient entropy to give us a reason to continue to exist. Whatever computer system that houses myself in between bodies would have to be pretty failproof and able to harvest energy from basically the fabric of the universe itself. Sounds pretty far fetched, but remember, with a technological singularity, you could solve much more difficult problems than that. Except maybe the end of the universe, that might require some serious thought. At least to come up with something more creative than just time traveling back to about 13 billion years after the big bang to when things start to get interesting. The tricky thing to consider is what's to say that hasn't already happened, and maybe I've just decided that lives are less boring if you don't remember anything else.
  5. Matt328

    More Deferred Rendering

    It's about time for my bi-yearly post here at gdnet, so here goes. I've gotten a single directional light working, a huge milestone after shelving the project for the better part of this year. The directional light is still being rendered directly onto the main render target, and my next task is to break out another render target and texture, and handle combining light rendering passes onto that. Once that is working, I'll need to write another technique in my shader to handle combining the lightmap texture with I'm guessing the color component of the g-buffer to produce the final image. Attached are some screenshots, because, everybody likes screenshots. #1 is of the separate components of the g-buffer, with just my skydome, which I'm very proud of, and kinda sad it stopped working. #2 is pretty much the same scene, only with the directional light rendered onto the background. #3 shows the directional light after some time has passed and the sun has kind of gone down. The reason I am so proud of my skydome is because I draw the sun onto the skydome in a pixel shader program, and moved the sun's position across the sky, and use that to calculate the direction of the single directional light I am rendering. I used to have this exposed to a Lua script, which I'm not remembering why I stripped out at one point. Some of you might remember seeing a render of the sun and a terrain I used to have as my avatar on this site a long time ago. That was made with a previous version of this project, probably prototyped in XNA back then. Once I have the rest of the deferred rendering in place, I'll go back and see what needs to be done to draw the skydome. I'm guessing I will just have to draw it last, in its own pass and there will probably be a little refactoring of my renderer class to support that. I sat down last night and actually came up with a set of requirements, more of a roadmap of things I want to implement for this project. For now it is just a hobby, but the roadmap does lead to it becoming a game in the distant future. Just doing that has given me alot of motivation, seeing a clear beginning and ending point, and how much more fun some of the later features will be to create once I've gotten some of the groundwork out of the way. Hopefully there will be another entry soon with screenshots of my completed deferred rendering. Possibly with or without a sky.
  6. No one click the link in my last status, apparently my twitter account was haxed or something?
  7. Local unemployed mam earns $355/h. (Online). find out how, Click here http://t.co/NS61ofJ
  8. Those two concepts don't necessarily have much in common, other than the fact that I've finished one and started another since my last journal entry. I'm fairly pleased with the model loading. At first I was just loading models in the Milkshape3D format, which due to the way the format is optimized for, well, Milkshape itself, the processing I had to do ended up being a little sluggish. It took almost 3 seconds to process a model with around 12k vertices. That was ok for awhile, but has been on my list of things to rework for awhile now. The direction I took with fixing this up was to make up my own file format that would sacrifice a little storage space for extremely quick load times. I wanted something that would pretty much come straight from disk into vertex and index buffers with as little processing as possible. Following is a spec of the format in its current iteration: UINT version; UINT nameLen; char[] name; UINT numMaterial; Material { short Index; char name[32]; float ambient[4]; float diffuse[4]; float specular[4]; float emissive[4]; float shininess; float transparency; char mode; char texture[128]; char alphamap[128]; } UINT numMeshes Mesh { UINT nameLen; char[] name; UINT materialId; UINT vertexLen; VertexPositionTextureNormal[] vertices; UINT indexLen; short[] indices; } Its really simple and basic and doesn't have many of the bells and whistles other formats may have like bones or animations, but adding those in shouldn't be too hard, and is something I think will help me better understand skeletal animation in the long run. I've also written a Milkshape plugin to export models into my custom format here, which was a fun and learning experience. And for the results, that same model it took my ms3d loader over 3 seconds to load now loads in less than 200 milliseconds, a huge difference. This will come in handy down the road when I want to load models in on the fly. After all this, I have a complete pipeline for creating models and resources in Milkshape and efficiently loading them into my engine. On to deferred rendering. I'm not as pleased with my progress on this as my model loading, but I think I have a pretty good start. I won't even try to explain many of the details of deferred rendering here, other people have already done a much better job explaining it than I probably could. The point where I am with it, I'm calling 1/3 of the way done since I've gotten the first of three steps finished and working correctly, creating what's called the g-buffer or geometry buffer. I'm not on my dev pc at home or else I'd post some psychedelic looking screenshots of the separated components of the g-buffer. Overall my existing forward renderer was easily adapted to deferred rendering without too many major structural changes. Hopefully I will find some motivation this weekend to get this project to 2/3 of the way finished.
  9. I have a twitter account. Now what?
  10. Matt328

    Short Update

    I had read a little about that way of doing it, but couldn't find many samples. I was still unclear a) how to call the delegate from my native C++ and b) if there would be any issues converting a std::wstring into a System::String^.
  11. Matt328

    Short Update

    Found it. Right click a managed project, 'Properties', then the 'Debug' tab contains a rather obvious checkbox named 'Enable unmanaged code debugging'. And output from log statements in my unmanaged code are showing up in VS' output window again. Brilliant!
  12. Matt328

    Lua Part (LuaParts.MaxValue)

    Wow, 8 or 9 years. Keep it up, your Heiroglyph project is one of the better resources for DirectX 11 code samples I've been able to find.
  13. Matt328

    Short Update

    Keeping in line with my rule #2 from last night's post, I was able to get my logger to send its log messages to my WinForms app. However the means are a little questionable. Calling native code from managed wasn't too hard to figure out. I created a C++/CLR dll which interfaces with my native library. The native library is compiled as a static library, so I'm not quite 100% on exactly how that works, but it just sorta does. In order to have my logger (native) send its log messages up to the Winforms gui, I would have had to do the reverse of this and have native code call managed code. An afternoon reading various articles on the subject didn't really talk me into wanting to try and implement something like that. It would have taken seemingly forever, and not had much payoff as this would probably be the only thing I would use it for. All that justification being presented, I decided to have my gui request log messages to display. I created another log target for my logger that would queue up log messages sent to it, and once every frame, the gui drains the queue and displays the messages. Its kinda kludgy and hacky, but it works for now. Now I just need to figure out why the VS debugger won't hit breakpoints set in my native code.
  14. Matt328

    Lua Part (LuaParts.MaxValue)

    Integrating Lua scripting into my game didn't exactly turn out as exciting as I thought it would. It is pretty sweet to type cube:SetPosition(x, y, z) in the console, and actually have the cube move around on the screen though. I'm not feeling like detailing much of the implementation because I don't think its really anything special at this point. A decent starting point and something to refactor a bit later on, that's all. And that's good enough for now. I'll come back to this thought at the end. Working with and thinking about interfaces between Lua and C++ did get me thinking again about my .Net WinForms gui. I had originally started that project with the intentions of it becoming a generic game editor using my C++ engine, but got quickly frustrated trying to abstract and generify everything. In case you haven't noticed by now, I only program at home out of boredom and its usually fueled solely by the randomness of my creativity. I have a hard time sticking to one project for long enough to get as much work done on it as I would like to. Contributing to that even more lately is work is pretty demanding of my creativity and in the evenings, on a creative level, I feel much more like consuming (playing Fable 2) than producing. When creativity does come, it's hard to keep it going for the weeks on end I would need completely implement a certain feature. I'm thinking about bringing back the .Net Winforms gui I had started, but making a few changes and gearing it more towards being just tool to help in development of my specific game, and gradually make it more generic over time. Maybe if I have some different options of things to work on I'll be more likely to actually work on one of them instead of thinking I'm tired of that maybe I'll start a new project... I've also made a few rules for myself. Rule #1: No more deleting everything and starting from scratch! Rule #2: To facilitate not starting from scratch, don't try to make everything perfect in the first attempt. Its much easier to refactor than to start from scratch. I'd be interested to hear if any of you guys have any rules you follow to keep yourselves on track with hobby projects.
  15. Matt328

    Lua Part 1

    My last post did say something about once a week, so here I am. I was away for most of the weekend, but did manage to work on Avalanche on and off for most of the day Sunday. I set up a project to test out the Lua api and got a few things hastily working, the main ones being linking to the Lua libraries, registering functions and being able to call a Lua function from C++, and vice versa. I realized I will need some sort of console window to enter Lua commands in realtime and kinda got lost down the rabbit hole setting up such a console using plain Win32. This felt way more painful than gui programming should be, but I powered through it and am pretty happy with the results. As with the Lua test project I created, the code is pretty ugly and relies on global variables and free functions floating all around, so my next goal will be to clean that stuff up and make each of those pieces a little more self contained. I'm feeling like scripting in a game can be a slippery slope. If you don't draw a line somewhere between what you want to script and what you want to code, you might end up with a game completely written in Lua. I'm going to err on the side of caution, and initially only expose things that will help speed up development to the scripting system. My plan is to write some reusable code to mainly allow for setting shader variables through my console, and to use that in picking up where I left off with my sky rendering I started in XNA. Once that is all established, it shouldn't be too hard from there to write a script to control a day/night sequence. Possibly tomorrow look for some more details of how I implemented the console window and maybe some ideas about encapsulating some of the interfacing with Lua.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!