next »

[ThemsAllTook]

Glad to help!

[VortexCortex]

Working on a palette editing tool for reduced palette images.

Specifically: Batch image processing for re-indexing large sets of limited palette (color quantized) graphics from one palette set into another palette.  Currently working out a 3D color space "similarity" (distance) calculation that's closer to human perception of color, with fudge factors (weights) for preferred smallest difference per color axis.  Eg: remap an image and prefer closest hue and lightness over saturation.

I removed a square root and work with distance squared for comparisons, but now I have to compensate because the color distances don't scale linearly...

I can do a simple batch remap in GIMP, but I need to take into account multiple destination palettes for the color difference to due to banded (quantized) lighting level palettes.  Otherwise bits of stuff can end up "glowing in the dark" or changing hue under darker palettes.

[TomHunt]

attempting to write a simple scoring system for the maze game i'm almost done with.

game programming at its most essential.

[powly]

Isosurface meshing, part n+1. After I get some smoothing done this version will be pretty okay.



Edit: yeah!

[SeaWyrm]

powly, whatever that is, it looks awesome!
Me, I'm trying to figure out how best to read/write my game's level structures and data to/from files in C++. It kind of scares me, I've never really done this before and I want to pick an approach that isn't stupid.
I mean, basic .txt file I/O, sure, that's easy, but. 

[Dataflashsabot]

As well as reinventing the "vector/matrix class" wheel yet again, I'm also making a header-only class to simplify binary file I/O.

Code:

BinaryFile test("test.dat");
int32_t val1 = test.read<int32_t>();
uint16_t val2 = test.read<uint16_t>();
test.skipBytes(3);
uint64_t var3 = test.read<uint64_t>();

The idea is to avoid having to worry about file modes, endianness, etc.

[powly]

SeaWyrm, just saving all the important structs with fwrites is usually okay, though the produced files are not especially hand-editable

And my system is a '3D texture goes in -> mesh comes out' kind of solution, nice for lots of stuff where analytic surfaces need to be rendered. Just fixed a bug in it, the first one is a bumpy 128x128x128 render and the other two are fixed 64^3 and 256^3, in... I don't know which order, I guess 64 comes first Though the function is a metaball sum so it's a rather good case for the algorithm - it gives way worse results with hard angles and such.

[pixhead]

Working on making a level editor for my current project. This is the first time I've ever made one from scratch, and it's not nearly as hard as I thought it would be.

It's a nice break from the masochistic nature of programming games in c++

[ThemsAllTook]

SeaWyrm, just saving all the important structs with fwrites is usually okay, though the produced files are not especially hand-editable

Not especially portable, either. If you compile for a different platform or CPU architecture, your endianness, struct packing, and type sizes may be different, which will render your data unreadable. Works fine for a temporary solution if you're not ready to worry about that stuff, though.

[Will Vale]

Glue code to connect my new sound support to the game engine. Decided to create an effects module as a container for other things later, like particles.

Really pleased with the data-driven stuff in my engine, all the code I wrote feels functional rather than boilerplate (I hate boilerplate) and without any further effort I can add

Code:

	CaltropFireEffect
	{
		type = "sil::fx::EffectData"
		clip = "resources/sound/rocket_explosion.wav"
		cue = 1
	} 

to a text file to have it load & normalise the wave file, build it into the data library for the game, and play it when an entity using the component receives an event matching the cue.

I still need to think about the events a bit, they've only been used a little so far and I'm not sure if what I'm doing at the moment is really the right way to handle things. But the entities + components work great.

Will

[mono]

So this is in a step event of the obj_player.

Code:

if place_meeting(x,y,obj_stillwater) && vspeed > 4
    sound_play(watersplash_1);

Why no work ?? 

[nikki]

you need to throw rock in water then splash will come 

[makerimages]

Make the x,y look like this: self.x,self.y

[mono]

Make the x,y look like this: self.x,self.y

Still no go. This might not be the optimal way of doing it. I want a sound to play once just when the player hits the water.

[R.D.]

Doing music generation for college:


The arrow spin arround bases on the given beat per minute.The middle thing also bounces to the beat and the little particles represnt a note given through a midi device (Using a Midi Guitar here). Via the Counterpoint theory I then let wall bounced particle create a natural sound pattern.
It makes more fun to do the graphics stuff tho :/

[VortexCortex]

This is a hex editor written in 16bit ASM.  No, look again.  The hex on the screen is the machine code that is running to make the image you see.

The full hex editor fits within 466 bytes, so it fits in a boot sector.  You write the binary directly to a boot sector, then boot from it.  Now you can edit raw RAM in memory.  That's right.  I edit machine code as it's running to add new features to the editor at run-time that didn't fit in 466 bytes.

07C0:0000 (shown above) is where every x86 PC loads the boot sector and starts off execution.

You can scroll over to B800h and write memory to change the colors of what you're actually seeing.  You can go down to the 0000:0000 range and see the keyboard's ring buffer being filled as you type.

You can pick a spot in RAM, and write machine code in hex, then press F8 and Jump into the RAM you just edited.   Saving?  You want to save?  Write the Machine Code to move blocks to C:H:S locations on disk, then run it.   Loading?  You're in the same boat.

You want to navigate?  Keep a table of places to jump in RAM, and jump to it, then jump to the seg:off represented under the cursor in your table.

With this most basic tool one can build everything else you need for an Operating System.

When I get pissed off at JavaScript, C, C++, NASM or all those other high level bullshit languages I blow off some steam and code in straight machine code.

That's what I'm coding right now.  I'm coding a damn OS kernel in machine code, because I just found some new hell in JS that's absolutely retarded.

You want to join me?  Here's my hex editor, written in ASM, and the boot image.  Want to run it?  Write it to a boot sector and restart.  Note: I'm not responsible if your system never boots again.

[ALourenco]

I'm Actualy programming a Map Editor for my new project in C++ using IndieLib. It's going well and I'm really excited about starting Producing it.

[sublinimal]

This is a hex editor written in 16bit ASM.

I appreciate this.

[Goran]

Using 3d voronoi diagram algorithms to break walls made of voxels!

[Will Vale]

That looks awesome!

I'm still wiring up effects - I had "Effect" as an entity component but it didn't feel right. Now the entity component is "Trigger" and effects live in their own little system, independent of entities.

This makes it easier to do fire + forget stuff (like impacts) plus effects in general are much cheaper. You can still have an effect follow its entity if you want for continuous stuff.

Gasbags now makes different (horrible) noises when things happen. I think this is progress.

Will