While I do like this idea; I think perhaps implementing non-rectangular clipping is a little beyond the scope of this library However, a function such as gfx_BlitArea that does gfx_BlitCircle would probably have better performance anyway; does that sound like an acceptable solution? Basically, the programmer would draw to the back buffer, and gfx_BlitCircle would then copy a circle from the buffer to the screen.

I do like that. That's basically the same thing.

Here's a list of changes; you should definitely update

- LibLoad v2.0 format is used for libraries, this helps reduces their size
- Libraries are preconfigured to be sent to the archive
- graphx v4 is out; which fixes a few things and adds gfx_Lighten and gfx_Darken (Screenshot below, graphics demo 11 of the toolchain)
- Changing user header files triggers a rebuild of source files
- Some random cleanup of examples

Download toolchain: https://github.com/CE-Programming/toolchain/releases/latest
Download libraries: https://github.com/CE-Programming/libraries/releases/latest



( I wasn't able to add the circle thing yet )

Awesome job on the update, but quick question. Is it possible to make the scaling much more specific? Right now it's like 1-5, right? If we could make them increment by one pixel or something that'd be great. If you wanna look at my contest entry, you can see what 1-2 looks like when I attempt to do depth.

Yeah... it will be slow though Don't expect super fast results

Anywho, updates to the toolchain include fixing of defines, proper keypad scanning examples, and the ability to easily set/get the OS date and time with some functions in tice.h

https://github.com/CE-Programming/toolchain/releases/latest

Good to know about that. Don't feel super obliged to do it, though, I don't need it right now. Thanks for updating the keyboard examples

Another feature request, put into eloquent words by Kerm: "My good, generous MateoC: I humbly desire background support if and when you have the spare time for it."

Thanks for all the work!

I'm loving the update so far! I've run into a snag, though (not related to your work). I have a function to procedurally generate a tree, which I think works pretty well. However, I want my game to have seasons, so I want the leaves on the tree to turn brown, fall off, and then grow back over the course of an in-game year. To do that, I imagine I need to know the coordinates of each leaf pixel. Since the leaves are drawn using circles, it's hard to know exactly which pixels are leaves and which aren't.

The only idea I've had so far is to figure out the min and max x and y coordinates of the tree, and then run a nested for loop to check every pixel for being a leaf, and then store the coordinates in some massive array. But that's slow, takes up a lot of memory, and I'd be doing that for every tree. Do you have a better idea?

If possible, I'd like to not touch my tree-generating code. It took a lot of tweaking to make the trees look like trees

Thanks for all your work! If it weren't for you I'd still be coding in TI-BASIC.

The way that I would do it would be to just store the location and radii of the circles that you draw for the tree leaves first. Then as the seasons pass, simply change the palatte color of the leaves which will automatically update all of your trees at once. When it comes around winter when the leaves fall off, redraw the circles but make them smaller -- since you previously stored the locations and radii. Then when spring comes around you can gradually grow the circles back until they are full again. Hope this helps

This is perfect, thanks!

Hey, I think I might have found a bug. gfx_RGBTo1555(255, 255, 255) currently appears to return 0x7FFF instead of 0xFFFF. If you set one palette entry to gfx_RGBTo1555(255, 255, 255) and another to 0xFFFF you'll see a very slight difference. If you can't, try loading it onto your calculator and turning it sideways so the screen turns negative.

edit by moderator: please edit rather than double posting within 24 hours. Thanks!

Yeah, I know the issue is that I need to add the lsb of green to the msb of the 1555 color. This adds a little bit of code to the resultant, but I guess it is probably worth it.

Cool, thanks

Edit: Working though some techniques, I'm finding it would be very nice to be able to draw masked shapes (so they only overwrite index 0). Would this be in the scope of the SDK?

No, that would probably be too slow for thing -- this is just a simple graphics library. However, a function could probably be written to perform the same task using pointers and custom functions.

Alright, I'll do my best! Thanks

Edit: Okay, I got the masking thing done. The only thing left with the trees is to make the leaves disappear in Winter. It'd be easy to make them fade to a specific color, but the sky changes color from day to night, so it's not quite that simple.

I'm thinking I could do a linear interpolation between orange (the color of leaves in fall) and whatever the current sky color is. Since this interpolation is going to occur over ~8 minutes, I'll have to change the leaf color mid-transition to match the sky color.

I'm familiar with linear interpolations in 24-bit color, but I'm not sure about 16, what with the extra green bit and all. How do you think I should go about this?

Thanks for all your help

Edit 2: Never mind, I figured it out. Happy holidays!

Thereis a new update to the toolchain and convpng that totally revamps and fixes compression since everyone seems to want it You can check out graphics demos 5 and 7 for useage, and the new header file "decompress.h".

https://github.com/CE-Programming/toolchain/releases/latest

For comparisons:


Input Image


ConvPNG outputs:
no compression = 52802 bytes
old compression = 29966 bytes
new compression = 20881 bytes

This is fantastic, thanks!

The new version of the toolchain is here! It adds the ability to compress your programs easily from the makefile, and fixes a compiling bug with one of the demos. If you haven't updated, you should

Update: https://github.com/CE-Programming/toolchain/releases/latest

Also, there is more documentation for all of you who are just starting out! Feel free to check out the github wiki: https://github.com/CE-Programming/toolchain/wiki

Is there support or will there ever be support for tile sizes outside of powers of 2? I'm currently trying to work with 20x20 tiles at the moment.

Sure I'll add it this weekend probably

Cool man, thanks!

While you're at it, will you also add support for sprites of a size greater than 256x256?