Jump to content

  • Log In with Google      Sign In   
  • Create Account

CC Ricers

Member Since 04 Jul 2004
Offline Last Active Feb 27 2016 04:44 PM

Posts I've Made

In Topic: Programming fake 3d using sdl?

13 April 2015 - 05:44 PM


Do you have a specific reason for not wanting to use OpenGL? A self-imposed limitation to experiment with a technique is just fine, but if you're of the mind that OpenGL isn't worth learning to do this, you might want to reconsider.


Raytracing seems to close to what I was looking for. Because I have not done this before I did not know what to search. Now that I have done just a little bit of searching it seems that using raytracing in a video game is not a good choice unless everyone is using a server farm to play the game.


Now I'm getting into some opengl questions(yes and no are not what I'm looking for). I would like to know the api calls or a link to tutorial would be nice.

1. Can I map a png to a plain in opengl and still have transparency?

2. Can I map only a portion of a image to a plain?



You might actually be looking for ray marching. You can more easily test intersections with objects (such as your plane) and use a fisheye-like projection to curve the rays to produce the sphere effect. Then animating the plane movement is as basic as off-setting through the X and Z directions.

In Topic: Content pipeline

13 April 2015 - 05:35 PM

In addition to what Hodgman said, Microsoft provides documentation for the .xnb format and a parser for it which is written in native C++. This parser outputs information about the original file data and format as it's encoded. This will let you load .xnb's in a non-XNA environment. The MonoGame team probably used this to write the pipeline code for their own framework.

In Topic: Lighting and what else for a good-looking voxel game?

07 April 2015 - 01:44 PM

I use some fake directional-based ambient lighting. This is what it looks like in my voxel engine. The idea came from this article on image-based ambient lighting but I kept it more simple and instead am just using the six sides of a cube to gather lighting.


It's a simplified version of what Swiftcoder posted. The sides facing the skydome have different tints of color which change during the day/night cycle, as well as the intensity of the light bounce (how much they contribute to the final color). The sides facing the bottom are less saturated versions of the top colors. I only did this because the voxel lighting will block most of the light from the bottom sides anyways.

In Topic: How should systems pick which entities to process? (Entity Component Systems)

07 April 2015 - 01:27 PM


I'm seeing some comments in this thread suggesting that like components should be in an array (and not stored on the entity that they "belong to"), so that they will be laid out sequentially in memory to take advantage of spatial locality when they are processed each game loop. Is this a premature optimization, or is this an important design decision to make? If the data is stored in component objects, will it make a difference anyway (won't the references to those objects be stored sequentially, and not the actual data)?

The "premature optimization" quote is the quote which is most often misquoted and taken out of context, here.

Making a high level architectural choice of where to put some data (in this case because the code gets simpler to write, when you wont discard the type information for components and there is no useless typechecking in the entity to make up for it), is a completely different thing than obfuscating a function to microoptimize it before you know it was needed (what the quote is about and in later sentences is relativating).



This is the main reason why I am storing components in an array. It's not so much for cache optimization, but to avoid type casting on every frame. At initialization each System gets the array of Components it needs to work on. They get cast to arrays of the derived Component classes which are stored in the System. When entities are processed I can access the properties of each Component without doing any casting.

In Topic: How should systems pick which entities to process? (Entity Component Systems)

03 April 2015 - 05:10 PM

That's why I use a TilePosition component and ScreenPosition component.  A Tile system is responsible for finding the closest Tile position for a sprite's screen position. It also looks for any static sprites that have a Tile Position set at load time but not a Screen Position. The system sets the screen position for them according to their tile position. Additionally, you may also want the tile information to exist in an array or hash map if you want the fastest lookup times for handling collisions. If your level has tens of thousands of tiles it is a lot better to check collisions against moving entities by looking up tiles in a hash map or array, than to loop through the thousands of tiles for every entity that can collide.


I did what Phil_t does and put all components in an array, with their index indicating what entity they are a part of, and register at load time. Although I still tend to bitmask/null check at every frame, I eventually want to register very large quantities of similar Entities early. There really is no Entity structure defined in the code because they're implicitly defined by the array indices.