next »

[rosholger]

im finally getting back in my grove after a major code burnout! woho its fun again!

[Eigen]

im finally getting back in my grove after a major code burnout! woho its fun again!

[Quarry]

After brain frying for hours with Joshua I resolved an issue, feels good

[Rahrahrah]

im finally getting back in my grove after a major code burnout! woho its fun again!

Same here.. goodo jobo!!

[George Michaels]

im finally getting back in my grove after a major code burnout! woho its fun again!

I've just gone into code burnout/demotivation because I realized how stupid it is to reliably send numbers (or anything other than strings) over sockets...

[Garthy]

I've just gone into code burnout/demotivation because I realized how stupid it is to reliably send numbers (or anything other than strings) over sockets...

Have you considered writing a light API over whatever you want to do, and then using that? That way you just have to write the endian-handling data mangling code once, and then you can call your API instead, and forget those issues even exist. Sockets are sufficiently annoying enough to use directly that a light wrapper is almost always a good idea.

Most socket code I've written works with "packets", which are whatever data blobs I want them to be, based on the problem I am trying to solve. I fill the packet up with data and call a send function, and on the other side I call a receive function to give me the next whole packet. My direct interaction with sockets then reduces down to setup, closure, and the send and receive calls. Works quite well.

Hope this helps push through the burnout. Let me know if you'd like some more suggestions.

[goshki]

I've finally got music playback working properly on Android with Haxe/NME. Earlier I was using a standard HaxeFlixel music playback but it's very troublesome on Android (no music pausing/resuming, no looping, app crashes when there's an incoming phone-call). Fortunately, I've found a solution by Giggling Corpse (written almost exactly a year ago ) and with a few adjustments it worked like a charm. Now I can pause, resume and loop my music as needed. It can also be looped in an arbitrary point.

I think I'll make a custom HaxeFlixel plugin out of it.

[powly]

Starting to get pretty happy with my pseudo-random collection of classes to do GPU stuff easier. I can pretty much pull simple stuff from thin air now, I think it'll soon be time to see how it works on a larger scale.



(oh god, bbcode is hard to get right)

[SuperDisk]

I've tried for a while to find a working SDL binding for Java that works in x64. All that's available are 2 old libraries that are for Win32, so I finally compiled the thing from source.

It took much more tedium because I clumsied up almost everything, but now that it's finally working I am quite happy

[George Michaels]

Starting to get pretty happy with my pseudo-random collection of classes to do GPU stuff easier. I can pretty much pull simple stuff from thin air now, I think it'll soon be time to see how it works on a larger scale.



(oh god, bbcode is hard to get right)

SIMPLE?! Dude, that looks beautiful!

[nikki]

Yeah, that.

[eigenbom]

I'm working on a sprite editor for moonman and it's going surprisingly smoothly..

[rosholger]

Starting to get pretty happy with my pseudo-random collection of classes to do GPU stuff easier. I can pretty much pull simple stuff from thin air now, I think it'll soon be time to see how it works on a larger scale.

img

(oh god, bbcode is hard to get right)

wow very cool!

[rivon]

powly: is that realtime?

[kamac]

Coded a mobile-virtual joystick ( like this one )

la la la la

[Tondo]

Finally got mouse-tracking working as I wanted for my game in python.

It shouldn't have taken this long but whatever, it's working now!

[powly]

Rivon, yes and no. It's okayish realtime too (could be way better, didn't fiddle with it because I just wanted pretty offline pics), but that image is the average of a lot of frames. You can try it out, too.

It's just a typical IFS, so it really is pretty simple, though beautiful if you get your parameters right.

[kamac]

My main game loop:

Code:

GRID->SetCamPos(cameraHandler::camX,cameraHandler::camY);
GRID->Process();
playerController::Process();
cameraHandler::Process();
actorEventHandler::handleProcesses();
commandEffects::loop();
// loop through actors. Update their animations.
typedef std::map<std::string,playActor*>::iterator it_type;
for(it_type iterator = GRID->actors.begin(); iterator != GRID->actors.end(); iterator++)
	iterator->second->Process();

Even though it's not 100% done yet, I am glad that it is clean.

[InfiniteStateMachine]

Ah the sweet feeling of a major performance improvement. I switched to an interleaved vertex buffer for the psp-vita and saw my performance rise from 15fps to way over 60fps.

It's very odd because every time I've switched to an interleaved vertex buffer my performance has improved subtly to significantly. Average programmer saw my post and attempted it and saw a 30% loss in performance.

I have no idea why. He writes in Ada though so it's hard to directly compare the code.

[_Tommo_]

I have seen the same, interleaved VBOs are faster.
And if you dabbled with CUDA it's obvious why: compact vertices fit into the cache of a shader unit, so when you read, say, the position, you're also getting UVs and normals for free.
Having all the attributes around in memory has (common) a worst case where reading each vertex attribute results in a miss, and this is obviously slow... in fact I wonder how the difference can be so small sometimes.

Obviously this depends on the architecture, so maybe there are FF pipelines which work differently and work better with non-interleaved vertices... dunno.