Custom image format update for anyone who is interested…

First blocks of data have been written and the colour table has been compressed from ~170KB to 30 bytes…

Now to decide on my preferred method for pixel indexing, RLE or no RLE… and how should one do the RLE…

*31 bytes actually, forgot the colour count

**32 bytes, forgot the fucking mode .-.

This project sounds cool

@ewpratten thanks! Going to make it open source so people can port the format around, currently building it in GML for use in my game engine but should be easy to port around

@lxmcf this is actually really cool, when was the last time you've seen someone making their own image format for (at least what I've understood) pretty much the hell of it? This is amazing! Nice progress!

Also I'm not familiar with those terms, what's the difference between RLE or not?

@chabad360 RLE is a really easy way to compress repetitive blocks of data, have a gander at the Wikipedia page

https://en.m.wikipedia.org/wiki/...

@lxmcf it really depends on what type of images this format is optimized for. Considering it's for a game engine chances are RLE would be useful, but then again maybe your expecting different types of images.

If your gonna be animating the images, maybe doing an h264 style only-store-changes thing might be very helpful.

@chabad360 nah doesn't support animation at this stage, primarily designed for pixel art or spritesheets, also going to have an 'image pack' style that would compress a max of 255 images into one file by using the same colour table to avoid duplications

Regarding animation, Sprite sheets is what I was thinking. Since it's gonna be animated, you could create (ok, I know I'm starting to sound like THAT boss, but) a system (RLE style for that matter) that only tracks difference in the image, and using the power of (well, ) numbers, you can cotrol which frames are shown. This would drastically take down image size, and make it something that's more useful for other systems.

Also for something like sprite sheets I think RLE would be very useful (as long as it's implemented smartly).

Image stacking... 32 bytes... If they were separate it would be around 8kb of color space data... Definitely useful, but idk if it should be a priority.

@chabad360 hmmm... Well i have added a dedicated byte that will indicate what compression algorithm it uses, might look into h264 like compression, for now I'm going straight without compression and open sourcing it once I get the very first image to convert from PNG and successfully load into a drawable image

Well... Good luck, and mention me with the link when you do release it, I'd love to play with, and even (depends on what I'm working on) contribute.

Can't wait to see it!

Does it support alpha?

@chabad360 it's legit in like beta at the moment haha, I reckon it'll be at beta release in another 8-24 hours...

As I said it is written in GML so only works in GameMaker studio 2 currently, but next step is to port to JS and C# for asset loading

@lxmcf who cares what language it's in!? If I can read and understand your codebase, I could (at least theoreticaly) port it. Also, especially if your porting it to C#, I'd be especially glad to help there (I'll have to brush up on my C#, but shouldn't really be much).

@chabad360 my code? Readable? Get ready for spaghetti with extra fucking noodle my friend

Doesn't mean it's not "readable", it just takes %250-%300 more time, but doable (I'll hopefully have enough time on my hands to work on an least on function at a time).

Alright another update, the first image binary has been completely written, an 8.4KB PNG has been converted into a 43KB LJI (Was previously 172KB), it may be a larger file but that is without compression, the format is best used on simple images but the whole idea of the image format is to provide easy palette swapping at load time…

Now to build a basic loader, throw it on github and work on alternate file modes (Compression and layout styles)

@Nanos I did briefly investigate the Huffman technique but feel like I would need to test it more before trying to actually implement it in something

@lxmcf regarding a loader I take it you're already integrated it into a GMS plugin?

@chabad360 not yet, by loader I mean just a few simple scripts to load the image at runtime, pricing to be difficult than I thought

Oh man