Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 28 Jun 2000
Offline Last Active Yesterday, 08:56 AM

Posts I've Made

In Topic: Interested in creating new game engine for a space adventure game; questions...

01 May 2015 - 10:28 AM

Sounds like someone just found out about the cancellation of 0x10c.


In case you are serious, dopefiend (which is a stretch)... start small. Make your first-person game in a level, then make that level into a ship, then make that ship fly, then make the consoles and machines in that ship interactive, then make them driven by some kind of virtual computer instead of a fixed set of game-driven screens and systems. There's no way you can make the entire monolithic thing in a single go, no matter how new or experienced a developer you are.

In Topic: Rendering Perspective Text

29 April 2015 - 06:48 PM

Why not transform just the "anchor" point of the text (usually the bottom-center of a line, or the top-left of the leftmost character, or something) to get a screen-space position for the text, and then draw your glyph-sprites relative to that position using Spritebatch. Round to the nearest pixel after calculating the screen-space position to reduce aliasing effects.


Unless you need your text to have size and rotation appropriate for billboarded objects in-world? Then create a billboard transformation matrix appropriate to the anchor of your text, and then just lay out your glyphs within that single billboard model space.


I'm not sure what you're asking for with "perspective text", nor why you think it's too much work to transform individual glyphs before passing them to Spritebatch. It sounds like a necessary step to get any individual sprites into the scene.

In Topic: Colition Detector Malfunction

26 April 2015 - 09:17 PM

bool testForCollision(const boundingbox& a, const boundingbox& b) {
    if (a.lry < b.uly) return false; // top of a is below bottom of b
    if (a.uly > b.lry) return false; // bottom of a is above top of b
    if (a.lrx < b.ulx) return false; // right of a is more right than left of b
    if (a.ulx > b.lrx) return false; // left of a is more left than right of b
    return true; // otherwise, they must be colliding somewhere
bool check_collision_down(int speed)
	int tempx=mainplayer.x;
	int tempy=mainplayer.y+speed;
	int tempblockx1 = ceil(tempx/32);
	int tempblocky1 = floor((tempy+mainplayer.height)/32);
	int tempblockx2 = ceil(tempx/32);
	int tempblocky2 = ceil((tempy+mainplayer.height)/32);
	boundingbox blockbelow;
	blockbelow.setposition(tempblockx1*32, tempblocky1*32, tempblockx1*32+32, tempblocky1*32+32);
	boundingbox blockbelow2;
	blockbelow2.setposition(tempblockx2*32, tempblocky2*32, tempblockx2*32+32, tempblocky2*32+32);
	if(  testForCollision(blockbelow2, mainplayer.colition)
	  && testForCollision(blockbelow, mainplayer.colition)
	  && ! blocklist[mainmap.getblock(tempblockx1,tempblocky1)].walkable
	  && ! blocklist[mainmap.getblock(tempblockx2,tempblocky2)].walkable
	) {
		return false;
	return true;

Rewritten for legibility (use the Code tags), and with a small edit for comprehensibility (the compound test in check_colition_down [sic]).


However, I'm finding this code pretty hard to follow. I don't know what you're trying to test.


Looking at the testForCollision() function, it appears that your coordinate system increases upwards and leftwards. This seems to conflict with the idea in the lines where you initialize tempblocky1,2, where you add the player's projected post-movement position to their height; unless mainplayer.height is negative, you seem to be testing for the presense of two tiles, one above the other, at the player's top, not the bottom.


mainplayer.colition [sic] appears to be a bounding rectangle for the player; but you are using the rectangle unmodified, you haven't positioned or adjusted it to account for the +speed movement you're applying in your search for tiles to test against. Why don't you just use the coordinates in mainplayer.colition, instead of calculating them from mainplayer.x,y,height ?


Last of all, this tests two tiles at the player's top Y position, and only in the column containing the player's X coordinate. Shouldn't you be testing two tiles at the player's head, one at the floor() of their X position and one at the ceil(), and even that assumes that the player is exactly one tile, 32 units here, in width? Again, why not iterate over the mainplayer.colition rectangle to test all tiles across their width?

In Topic: IDEs vs editors

23 April 2015 - 08:57 PM

Throughout university, I never wrote anything that required an editor with more features than SciTE or minimal-install emacs. Then I entered the industry, and within a month found myself working on a Java-based industrial process training simulator, which had inherited over 10 MB of plaintext source. Needless to say, for about a month I resented needing Eclipse to get anything done. Then I learned to stop worrying and love the bo... err, IDE.


Nearly ten years later, I use Eclipse for Java, PHP, Flash (via Flex SDK), and C++ development. I'm sure there's better domain-specific IDEs, but there's nothing else that will let me step-through debug Java->JNI->Java in a single window, and let me debug Flash->Tomcat communications, and let me seamlessly switch from writing C++ to writing Java without re-teaching my fingers a whole different set of shortcuts for twice-or-more-per-minute operations like "Open Resource", or "Jump to Declaration", or "Find All References".


Plus, Eclipse's Refactoring capabilities are top-notch, and now an integral part of my prototyping process. I just wish it had better Git plugins; SVN is as good as it gets, since Eclipse's native concepts of version control ends at CVS's capabilities.

In Topic: Playing ogg file with openal and stb_vorbis?

19 April 2015 - 10:26 AM

Try using stb_vorbis_open_filename() instead; that returns an stb_vorbis*, which you can pass to stb_vorbis_get_info() to get an stb_vorbis_info struct; that will tell you the number of channels and the sample rate, which you then multiply together with stb_vorbis_stream_length_in_samples() to get the total file-in-memory size you will have when you've read the entire file, if you want to have the entire file in memory at once.


Then, you can pull the audio data progressively into memory as you need it, using the stb_vorbis_get_frame[...] or stb_vorbis_get_samples[...] families of functions.



Edit: just looked at the stb_vorbis_decode_filename function; it returns the number of samples decoded, and you told it the number of channels and the sample rate. Multiply those three together, and you get the total number of shorts in the buffer; multiply by sizeof(short), and voilá; size of that buffer in bytes.