studentTeacher

Members
  • Content count

    62
  • Joined

  • Last visited

Community Reputation

1077 Excellent

About studentTeacher

  • Rank
    Member
  1. Hey all! As a continuation of my last post, I decided to move onto creating some debugging/feature tools, as well as implementing a scripting language. This was basically a successful 2-for-1 special!! For me, networking and general client/server/browser work would be much simpler to do in Javascript, and should be performant enough. Though I have littler experience with Javascript, the experience I've had and the research I've done seems like it'll be a good choice. I also had chosen the language as my scripting language, since it's simple to learn and easily applicable to a variety of platforms and peoples. I've also been looking for excuses to use/learn the language This past week, I downloaded Node.js, which is backed by Google's V8 Javascript Engine. The code is definitely a bit convoluted, but seems very cautious and safe, and makes sense none the less! I delved right in, and got some simple examples running: Simple Chat Program, all Javascript. Uses browser for the clients. C++ to Javascript code, where I could use C++ objects and call C++ methods from my Javascript code. Easy enough! Combined the two above: Chat program, where messages got printed to the console and appended with the sender's information on the C++ side. The code looked like the following:[code=:0]// C++// Point example.//...static v8::Persistent constructor;// Everything's static except the internal field of the class instance.static void init(v8::Handle exports) { v8::Local tpl = v8::FunctionTemplate::New(New); tpl->SetClassName(v8::String::NewSymbol("Point")); // This internal field is a pointer to the class instance. tpl->InstanceTemplate()->SetInternalFieldCount(1); // These methods need work, handling different method parameters is HARD. // These methods add to the "New" method a function pointer to a callback. // These method callbacks grab a "this" argument, the parameter arguments, // then grab the underlying object and call the same method, with the given // parameter arguments. I've hard-coded the arguments for now, but I need to // template-ize these methods and get it all working generically. addMethod(tpl, "getX", getX); addMethod(tpl, "getY", getY); addMethod(tpl, "setX", setX); addMethod(tpl, "setY", setY); constructor = v8::Persistent::New(tpl->getFunction()); exports->Set(v8::String::NewSymbol("Point"), constructor);} //...void InitAll(v8::Handle exports) { JSPoint::init(exports);}NODE_MODULE(addon, InitAll);// End C++ // Javascript var addon = require('./build/Release/addon.node'); var p1 = new addon.Point(129576, 165.567); var p2 = new addon.Point(124.9, 235.1423); console.log("P1: x=" + p1.getX() + ",y=" + p1.getY()); console.log("P2: x=" + p2.getX() + ",y=" + p2.getY());console.log(p1 instanceof addon.Point);// End Javascript These examples were brief and simple, but they got the main parts I needed to figure out down pat. From here, the C++ objects and methods lay in the engine, and Javascript runs the game and networking logic. The last issue I need to solve is creating an extensible wrapper for classes that I can wrap for the Javascript code -- surprisingly more difficult than one might think I hope I can get there in the next week or so! Best, ST
  2. Early days (again)

    Good to see the 3D back again. The work you were doing was awesome! I hope things work out better this time around :)
  3.   I've been looking at websockets -- though that was a keyword that escaped me for a while. What I've decided to do is run my engine as a shared library alongside the V8 engine (embedding C++ functionality from my engine into my javascript code), and use Node.js w/Express and Socket.io for my webserver. This ends up being powerful and simple to do, while also letting me get my scripting language out of it, which is what I wanted. I can already pass data form the engine to an HTML page! It only took about a couple days to implement it :)   Now to add structure to the engine (C++), and pretty up the browser portion, and I'm done. Then I just need to create requests and responses as I come up with them. Luckily all requests can be handled in C++, so that makes my life a lot easier to pack into the engine. I'm thinking in a couple weeks I can have functionality done, and I can work on form and style over time.
  4. WIP 5 -- Transparency Woes, Debugging and Refactoring

        Luckily my graphics issues were on the CPU end :D So this made debugging easier. I'm also going to need something that picks at my engine since I'm apparently bad at writing logs and profiling (something like a webserver lets me pull data where and when I want). It's all a learning experience anyways, and this is a hobby, so there's no rush for me. Take my time, and in the end I could have a freaking sweet engine or tool suite to share with the world :)   I'm at a good point to make these tools (engine's pretty fleshed out, almost at the point of no return, so a big change like this should come sooner rather than later), plus I'm a senior about to graduate, so some cool tools like this can flesh out my web development side for interviewing and programming examples.    The nice thing is I started playing around with Node.js and the V8 engine, and I can get it all working with a webpage fairly easily (I've already cone a chat program that exchanges messages and objects with C++ code, and even logs on the server's side in C++ using my logger)! My engine will just be a library to make calls from with the JS code -- so I also now have a simple-to-use scripting language, which I was planning on from the start :) It's a win-win situation. Now to write it....that's my task for the next couple weeks.
  5. I guess my last question would be this then: Does anyone know of any good C++ alternatives to things like Node.js that would be easy enough to embed in my game engine and still just as functional as Node.js? Maybe I've been looking up the wrong side of the tree or something, so i think it's best to ask.
  6.   I think it's more so that I can get it working in C++, but the time and effort I'd put into that, for something that I find more verbose and difficult to use anyway, isn't worth it. Using Javascript (which I've done for a chat program that uses the browser as the client) was simple, barely a few lines of code, and was concise and easy to read and understand. I just don't see why I should take the time to finish figuring out the C++ version when it won't be as nice or as clean as the Javascript version.   Now with  that  being said, I just wanted to check my sanity at this point. Do scripting languages get used in this way (as I will use this as a scripting language later anyways)? Or is this bad practice that I change later? The javascript portion is going to end up with access to all Game Objects and assets and will be able to modify/change/snoop on them all in the browser....   As I see it, I will use Javascript to make my game. When it's not performant enough, I can fall back on C++ to do the job for me. So my thoughts here are that Javascript is used for anything it can be used for, and C++ is ONLY used when necessary, like pathfinding or AI behaviors, or the RenderingEngine portion of my engine. Previously I thought I'd use C++ for the Engine, and Javascript for the game. The issue I'm having is networking, webserver stuff, and all that jazz is SO much easier in Javascript for me that parts of the engine are moving over to Javascript -- and in theory, I'm unsure if this is a safe move or not.   In the end I get that it boils down to me and what I want, and what I need to meet my expectations, I just wanted to see where I'm at and where theory and general practice usually leans :)
  7. WIP 5 -- Transparency Woes, Debugging and Refactoring

      It wouldn't let me make it bigger :/ I changed the font size multiple times....It's something to do with copying from a word doc (first time I did it).
  8. Hello,   Currently, I've been looking forward to making a wide range of related tools for my game engine (written in C++, scripted in Javascript). I've even looked at going to the point of having a browser-based game, but for now I want to keep the engine working as-is. Recently the tools I'm looking to develop require HTTP requests from a browser to be handled by a webserver embedded into the engine, allowing for developers to do a variety of things: snoop, change variables, check game flow, etc. I'm already planning on using Javascript as a scripting language, especially with SpiderMonkey's IonMonkey doing JIT compiling and such.   I've had a hard time getting myself getting this webserver working in C++ -- and frankly, JavaScript seems to have so many better solutions to getting a lightweight webserver to work (e.g. Node.js and Socket.io) that I find myself wondering if I should just implement this portion in javascript. I can combine this "scripted" portion (regardless of how important this tool is, and how embedded it will be with the engine's data and core, the engine is still C++ in its overall core I guess) with the engine and some browser tools. Before I take this step, I wanted to get some advice, or see if I'm missing something in the bigger picture of things.    Does this sound like a good idea? Am I missing something, or totally off course? I'm looking for suggestions, questions, and corrections. Please help me out!   P.S. I'm not sure if this is the right forum to place it in; I was between different forums and decided to place it here for general-purposes sake....   Best, ST
  9. [font=arial][size=2]Hey![/font] [font=arial][size=2]So I posted the mid-week update of my transparency work earlier this past week. The results looked nice, but shortly afterwards, I realized I had some memory issues and it became a mangled mess. What was happening was I had my INDEXARRAY pointing to the array of indices stored in a VertexBufferObject in the mesh. When I passed that same array to itself for copying, weird glitches and a lot of memory access violations occured, mangling the meshes pretty bad. I cleaned that up, and fixed some of my sorting code to only perform sorting when crossing a block boundary (x-, y-, or z-plane). There's quite some optimization to be done there, but for now, it's good![/font] [font=arial][size=2]Two things popped up during this process this past week however, and I need to address those before getting too deep into the engine. The first is Debugging. Currently, I have the most simplest form: logging. This has been fine so far, albeit with some print statements here and there while ironing out details, but when it got to the point of debugging some of the finer issues of transparency debugging, I realized my setup isn't ideal. The main issue I had was the lack of a "needle" to poke around into the executable. I wanted to peek in, grab a variable, change it's value, and see what happens. I wanted to set up the game at a certain point and see how things traverse from there. These are all useful things for debugging various features, now and later.[/font] [font=arial][size=2]I also ran into the issue of transparency causing such a big change to the engine. I hacked this solution together; great! But now I have to clean it up. That'll take some time! I need to work on a better habit of programming in order to handle the situations of big structural changes with better ease. I'll have to try different things and see where I end up.[/font] [font=arial][size=2]All in all, this experience was a wake-up call. I need to work on a couple tools before moving forward (luckily I've got quite some interest in these tools!) and then focus back on gameplay. Looking ahead at some big changes (World generation, chunk state management, disk handling, etc.) this change and these tools can be very instrumental in creating a good system. Heck; what's an engine without it's tools and flexibility???[/font] [font=arial][size=2]And here we leave at what to work on. I'll be working on incorporating an HTTP server into my engine, in order to flesh out debugging and feature addition. This will be a simple data server coupled with a couple HTML pages for displaying and manipulating data. These have been done before and I'm looking for good libraries and examples, so I'm hoping this won't be a terribly long diversion! Once it's done, onto more memory related things (disk I/O, paging, world gen, etc).[/font] [font=arial][size=2]Best,[/font] [font=arial]ST[/font]
  10. Useful debugging tools and features

    Cool stuff. I'm actually starting to look into that HTML Server stuff since it seems so damn useful, and interesting to learn! Thanks for the cool read :)
  11. Mid-Week Update: Transparency Woes (Pictures!)

      Nice! What are you using for rivers -- noise, erosion, or something else?
  12. Mid-Week Update: Transparency Woes (Pictures!)

      I tried that by doing cubes with spheres subtracted....looks fine! Hard to tell the difference between the last one above and the new ones though....I don't know if it's correct, but it looks good enough and realistic enough that I don't think anyone would complain. I'll look more into it. Thanks too! Your comment pushed me to finish transparency up real quick :)
  13. Well....been working on transparency, and here's some of the hilarious results I've had through the process: Aaaaaannnndddd.....that last one shows static sorting -- one round of sorting on generation, and that's it. Looks not too bad! When I work with movement, I've gotten a lot of flickering issues (see the crazy 4th image!); just some bugs to fix. Until next time! Best, ST
  14. Day/Night Cycle

    The atmosphere a simple change like that makes is amazing! Looks great :)
  15. WIP: Week 4 -- Transparency

    That sounds pretty good actually. I don't consider myself bottlenecked by my processor (I generate only a few chunks a frame, but over time, and with player's walking around by foot, that's a fine speed); I'm more worried about the rendering performance for the game, since there's just so many faces being rendered at any given render distance (which grows as performance and optimization occurs) -- as I reduce faces, I can push the render distance farther, and that means I have more time to generate far terrain, since it'll be so far away and already runs at a decent speed for generation.    And yet I still want to create an adaptive LOD system to push the viewing even farther! But I'm getting ahead of myself. I'll start with what I have, create gameplay, and work on LOD once I figure out a good way to do it (erm.....find out how to do it as good/better than sea-of-memes adaptive approach! ).