next »

[JobLeonard]

That was an hour well spent.

It appears so.

[joseph ¯\_(ツ)_/¯]

For the curious, this is what it does: https://soundcloud.com/evan-balster/perilymph-test-demonstration

It's coming along very well.

that is super cool

[Evan Balster]

I'm working on Perilymph madly and it's getting cooler and cooler...  I'll bring it up in the music forum sometime in the next week or two.


Anyway, came here to say that I've got a function called void stripShuffle() in one of my graphics classes and every time I read the name I think it's some corny pseudoerotic Megatouch game you'd see at a bar.

(Its actual function is to re-shuffle the vertices of a composed triangle strip into a polygon outline for the purpose of consistency with other geometry.  A special tessellation mode lets the renderer un-shuffle this data when setting up the VBO so it doesn't need to dynamically tessellate it.)

[Belimoth]

I just spent 5 minutes trying to figure out what caused my game to freeze.
I was attempting to play a screenshot

[Schrompf]

The framerate probably sucks.

I feel weird whenever I try to call up a function handlung a Gui::Button - Alt+M, b, u, t, t.

[JobLeonard]

I just spent 5 minutes trying to figure out what caused my game to freeze.
I was attempting to play a screenshot

Ahahaha, I can actually relate to that - making similar mistakes when taking screenshots of software I wrote. And there were the times when I helped out my friends with computer problems through skype, and I kept clicking on the video stream.

[SuperDisk]

The framerate probably sucks.

I feel weird whenever I try to call up a function handlung a Gui::Button - Alt+M, b, u, t, t.

Kinda like on Windows, starting Paint you can just do "Start -> P-A-I-N -> Enter"

[Klaim]

Evan Balster> Impressive work!

---

Code:

namespace 
	{
		class FuckingProtobuf
		{
		public:
			~FuckingProtobuf()
			{
				google::protobuf::ShutdownProtobufLibrary();
			}
		} const remove_memory_leaks;

	}
	

Made me giggle then made me sad.

Why this code:
The idea here is that because of the way Protobuf use globals internally, it makes memory leaks, or more exactly, your memory leak detector will report leaks, if you don't call this shutdown function before the end of the application execution (either before or after main() is ok).
Now, it wouldn't be a problem if these globals weren't tied to the dynamic module they were created in, which means that if you have dlls (yeah I know, you should avoid them, but I just can't by design, think about plugins for example) and you are on Windows (not sure it's true on other platforms) then you have to make sure each dll also calls this function.....
I'll hack something to automate this in my project later, but it's fucking annoying. I don't even have the option to use protobuf as a dll, which would solve the problem, because the authors says there can be some unexpected issues in this case on Windows.
Frankly I think they just are not willing to support Windows well, which is one reasons I was looking at alternatives like Thrift (that is not better on Windows support...) and Captain Proto which is made by the guy originally behind Protobuf.

[diegzumillo]

Hard-coded vertices for a piano keyboard.  That was an hour well spent.

Code:

Sequencer::UI::UI(App *_app) :
	Interface(_app)
{
	//Draw a piano.  Yes, this is clearly a smart way to do this.
	const float YE = .8f, YT = .7f, YF=.3f, YB=.0f,
		XK=1.0f/7.0f, XE=1.0f/12.0f,
		XF[] = {.6f*XK,1.2f*XK, 1.8f*XK,2.4f*XK,
			3.5f*XK,4.1f*XK, 4.7f*XK,5.3f*XK, 5.9f*XK,6.5f*XK};

	//C
	octave.shape(WHITE).build
		(XK*0, YB)(XK*0, YT)(XE* 0,YE)(XE* 1,YE)
		(XF[0],YT)(XF[0],YF)(XK* 1,YF)(XK* 1,YB);
	//C#
	octave.shape(BLACK).build
		(XF[0],YF)(XF[0],YT)(XE* 1,YE)(XE* 2,YE)(XF[1],YT)(XF[1],YF);
	//D
	octave.shape(WHITE).build
		(XK*1,YB)(XK*1,YF)(XF[1],YF)(XF[1],YT) (XE* 2,YE)(XE* 3,YE)
		(XF[2],YT)(XF[2],YF)(XK*2,YF)(XK*2,YB);
	//D#
	octave.shape(BLACK).build
		(XF[2],YF)(XF[2],YT)(XE* 3,YE)(XE* 4,YE)(XF[3],YT)(XF[3],YF);
	//E
	octave.shape(WHITE).build
		(XK*3, YB)(XK*3, YT)(XE* 5,YE)(XE* 4,YE)
		(XF[3],YT)(XF[3],YF)(XK* 2,YF)(XK* 2,YB);
	//F
	octave.shape(WHITE).build
		(XK*3, YB)(XK*3, YT)(XE* 5,YE)(XE* 6,YE)
		(XF[4],YT)(XF[4],YF)(XK* 4,YF)(XK* 4,YB);
	//F#
	octave.shape(BLACK).build
		(XF[4],YF)(XF[4],YT)(XE* 6,YE)(XE* 7,YE)(XF[5],YT)(XF[5],YF);
	//G
	octave.shape(WHITE).build
		(XK*4,YB)(XK*4,YF)(XF[5],YF)(XF[5],YT) (XE* 7,YE)(XE* 8,YE)
		(XF[6],YT)(XF[6],YF)(XK*5,YF)(XK*5,YB);
	//G#
	octave.shape(BLACK).build
		(XF[6],YF)(XF[6],YT)(XE* 8,YE)(XE* 9,YE)(XF[7],YT)(XF[7],YF);
	//A
	octave.shape(WHITE).build
		(XK*5,YB)(XK*5,YF)(XF[7],YF)(XF[7],YT) (XE* 9,YE)(XE*10,YE)
		(XF[8],YT)(XF[8],YF)(XK*6,YF)(XK*6,YB);
	//A#
	octave.shape(BLACK).build
		(XF[8],YF)(XF[8],YT)(XE*10,YE)(XE*11,YE)(XF[9],YT)(XF[9],YF);
	//B
	octave.shape(WHITE).build
		(XK*7, YB)(XK*7, YT)(XE*12,YE)(XE*11,YE)
		(XF[9],YT)(XF[9],YF)(XK* 6,YF)(XK* 6,YB);

	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*1,YB)(XK*1,YF);
	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*2,YB)(XK*2,YF);
	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*3,YB)(XK*3,YT)(XE* 5,YE);
	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*4,YB)(XK*4,YF);
	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*5,YB)(XK*5,YF);
	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*6,YB)(XK*6,YF);
	octave.shape(LIGHTGRAY).build(Shape::LINE)(XK*7,YB)(XK*7,YT)(XE*12,YE);
}

And yes the program is as cool as it looks.

I'm a sucker for music softwares! I want that. gimme! 

[Geti]

http://en.wikipedia.org/wiki/E-Type_(musician)

Heh, though on a more serious note surely that pollevent should be its own loop if you want to handle more than one event per game tick?

[Sir Wolf]

Got a good laugh out of easy mistakes.

I was implementing a new feature and wondering why it made some game objects jump wildly all over the place. The new code didn't touch object positions at all, merely observed them to make some calculations off of them. With some commenting/uncommenting experiments I narrowed it down to one line.

Code:

position = object.position += offset

Ah, well that was dum of me, accidentally put in += instead of a +. Well, that was an easy one, it should work now.

So I try it again, and it still doesn't work. This time I find all my objects getting piled up in the same position in the game world. Duh huh. I look at the line I just "fixed".

Code:

position = object.position = offset

[Geti]

The above error is always way funnier when it's late, you haven't been committing to your VCS enough and it slips in in a conditional. Of course you're compiling with warnings off because you have several years of legacy "unsigned mismatch" that you don't want to fix so it takes ages and ages to find that little innocuous "if( obj.id = RULES_ID ) //game rules object".

Recently I've been writing yoda expressions and I'm not sure if I like reading them or not, but at least they don't compile if you miss your second =

(for those that don't know, a yoda expression is something along the lines of "if( RULES_ID == obj.id )" - the constant cant be modified so if you try to assign the compiler will wake you up. )

[Iso]

Got a good laugh out of easy mistakes.

I was implementing a new feature and wondering why it made some game objects jump wildly all over the place. The new code didn't touch object positions at all

Similar kind of mistake made me laugh/go nuts the other night.

I hadn't touched the code that generated my worlds vertices. Yet suddenly after changing how the drawing code works, the vertices exploded and the world went crazy. It was all warped and seemed to get exponentially further and further away.

I'd forgotten that I changed the position vectors from Structs to a more complex Object... Yup, all the position calculations where I'd done something like:

Code:

vectorPosition = Vector.Position;
vectorPosition *= worldOffset;

Were now using object references and causing every vector manipulation to have a cumulative effect.

[Pineapple]

Code:

Method draw_line:vector(str$,xoff%,yoff%,ufont:font,wlimit%=-1,hlimit%=0,charlimit%=0,dontactuallydraw%=False)

dontactuallydraw

Ok

I had a perfectly justifiable reason for doing this but it still made my belly wiggle to see it again.

[Iso]

After working on the Entity Component System side of my game, I finally had the need to delve back into my segmentation/block code, as placing items in the world was causing the vertex buffers to be recalculated when it wasn't necessary.

There's some code in there that marks segments as "dirty" and therefore need updating, I forgot that I added a control variable when setting flags on the bitmask called "IsDirtyTouch", eheheh... Dirty touches.

[George Michaels]

I just wrote this line:

Code:

void*** g_entities = 0;

I feel like I've performed an eternal sin with all those asterisk's

[Geti]

fwiw you could just use a void* and cast to type*** when you want to actually use it. Having the dimensionality "built in" is nice though... I guess

What's the use case here? looks like you could have an entity_ref_t union or similar, so you've got some sort of "RTTI" and therefore some way to check your errors/sanity when you need to (and less (type***)g_entities everywhere).

Code:

typedef union {
    uint8_t type_id;
    struct {
        uint8_t type_id; //ensures that type_id is always available
        Tile* tile;
    } ref_tile;
} entity_ref_t;

Not sure if it'll be cleaner or not for you without knowing the use case though

[George Michaels]

What I had originally was an entity struct like this:

Code:

struct t_entity {
  unsigned int id;
  t_vector position;

  void* components[COMPONENTS_LENGTH];
}

... and g_entities was an array of those.

I decided to refactor it to just be an array of components, ie: each entity is an unsigned int and all its components are void pointers. The void*** is pretty much an array of arrays of void pointers. I'm using documentation on what each components type is in favour of RTTI because I'm too lazy to implement any sort of RTTI..

It works exactly how I want it to though, but I just feel so bad doing it for some reason lol

[Geti]

With that sort of system you don't really have flexibility with your components though as far as I can see, because each entity has COMPONENTS_LENGTH components and they're always there and present (or else presumably NULL).

I've found that it's great to be able to hold and control, say, 2 sprite components rather than build layers into the sprite component itself - means that a component is actually a component, instead of a container of components.

Same goes for physics shapes, sound objects, and most importantly scripts or logic components.
Having the position reside in the entity itself also looks like a bit of a hack.
I also dont think i've ever seen backwards t_type instead of type_t

Seems like you're definitely in that middle ground between entity and component paradigms. We do this in KAG and "it works", but a proper component system doesn't need entities containing the components... I won't rant about this philosophy stuff any more here though, it's not particularly funny.

[George Michaels]

With that sort of system you don't really have flexibility with your components though as far as I can see, because each entity has COMPONENTS_LENGTH components and they're always there and present (or else presumably NULL).

Every component starts off as null, then giving an entity a component is just making that void pointer point to something. So for example a position component, g_entities[id][COMPONENT_POSITION] is a pointer to a vector.

I also dont think i've ever seen backwards t_type instead of type_t

Haha I've been doing it like that for ages, I just like to see the type identifier first rather than last. Namespaces start with n_, global variables are g_, enum's are e_, structures/classes are t_, function pointer typedef's are f_, and function parameters are just _.

If you want to have a proper look at the source it's on BitBucket.