Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Feb 2013
Offline Last Active Sep 07 2015 06:10 PM

Posts I've Made

In Topic: Javascript/C++ Combo Questions (Networking/Tools)

22 January 2015 - 01:11 PM

Yes. Having a webserver in your game to serve XMLHTTPRequests?
No way. Look for websockets.
The feature you're trying to implement is extremely advanced and comes sure at a toll in terms of effort. Be sure to get a positive gain. I wouldn't do anything like this at engine level, maybe for the scripting system. Maybe.


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.

In Topic: Javascript/C++ Combo Questions (Networking/Tools)

21 January 2015 - 02:40 PM

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.

In Topic: Javascript/C++ Combo Questions (Networking/Tools)

21 January 2015 - 10:21 AM

That being said, it would probably be useful for you to at least figure out why you can't get the webserver working in C++. Even if you don't end up using it, the debugging experience and learning process will be useful to you.


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 :)

In Topic: Rendering Transparency with only One Color.

05 January 2015 - 12:39 AM

If you only have one fix color you could try to render the transparency value to the alpha channel and add the color in a postprocessing step. Here's some pseudocode:

0. init alpha channel with 1
1. render opaque meshes (to build up the z-buffer), leave alpha channel to 1
2. render the transparent surfaces to the alpha channel, use the z-buffer, but dont write to it. 
   Blending: new_alpha = transparency * old_alpha, with opaque = transparency 0.0 and fully transparent=1.0
3. use a post processing step to blend in the water color accordingly to the alpha channel:
   new_pixel = water_color * (1-alpha ) + old_pixel * alpha


Looks doable and easy enough to implement. Though I don't think this could work with textures....? Unless the post-process is just rendering the water again, but using the existing alpha channel to compute the final color? I think I'm starting to get it! :)




But this will only work if you really have unlit, single colored water (depends on rendering style). There are other ways, but i depends on your rendering approach (deferred, forward, lighting, shadowing....)


My rendering is forward, I have separate shaders for terrain, water, and instanced 2D sprites and 3D models, using OpenGL.

In Topic: Voxel data- best way to get neighbors?

22 December 2014 - 04:01 PM

Keeping a separate lightweight data map makes sense. Since I'm coding in C# I would use a Dictionary or SortedDictionary. Also, looks like the only way I can understand solving the connection of chunks that are still not in position would be to send events or signals as you said.

So in other words any assignment to an adjacent chunk should fire an event to tell that chunk to update its connections except for the one that signaled it.


Chunk X gets loaded, attempts to get connections to adjacent chunk locations via the Map or Dictionary but none are found. These connections are assigned null.


Chunk Y gets loaded and makes a connection to chunk X. This sends an event with a callback for chunk X to re-check its connections. X and Y are now connected to each other.

Yepp you got it! Therefore as your world loads/you load new chunks, the system automagically hooks everything up for you. If your neighbor is null, you can define the behavior -- I use a "null voxel" that's solid and non-meshable, allowing me to not render the sides of chunks at the end of the worlds. The other route is to be like Minecraft and to pass the world object everywhere, so any external dependencies just become calls to the world object (e.g. world.getChunkAt().getVoxelAt() or world.getVoxelAt(), etc.). 


As for what Ravyne said, that's where the system I'm working on now hopefully comes in. To allow for a more realistic world, where water updates propagate as far as need be, and chunk updates can happen whenever, wherever, I'm working on an adaptable, smart system that keeps in mind the memory cache. It rearranges my pointers and memory when necessary, and loads in data from further chunks when necessary -- keeping the world running well, even far away with updates, without taxing the computer too much. I'm nowhere near done however -- but speaking of the 0fps blog you've seen before, check out this: link. He has a good discussion about memory layout techniques, and I've seen some voxel engines take the interval tree route, fixing memory issues at the cost of a little more computation. As for me, flat arrays work fine, and I'll be sticking to that. Find what works best for you (and no need to optimize prematurely!) and run with it. :)