seanlego23 wrote:
I don't know if this is possible, but what about a clipping window that isn't a rectangle, but a circle? I just think that might be cool if someone wants to create a game where they're in a tunnel or something and you can only see so much around you.

While I do like this idea; I think perhaps implementing non-rectangular clipping is a little beyond the scope of this library Razz 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.
MateoConLechuga wrote:
seanlego23 wrote:
I don't know if this is possible, but what about a clipping window that isn't a rectangle, but a circle? I just think that might be cool if someone wants to create a game where they're in a tunnel or something and you can only see so much around you.

While I do like this idea; I think perhaps implementing non-rectangular clipping is a little beyond the scope of this library Razz 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. Smile
Here's a list of changes; you should definitely update Very Happy

- 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 Wink )
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. Razz
Unicorn wrote:
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. Razz

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

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 Razz

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." Razz

Thanks for all the work! Wink
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 Smile

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

90259025 wrote:
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?

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 Smile
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!
90259025 wrote:
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.

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. Razz
Cool, thanks Smile

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?
90259025 wrote:
Cool, thanks Smile

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 Smile

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 Smile

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 Razz 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 Smile

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.
samuelroy21 wrote:
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 Smile
Cool man, thanks!
MateoConLechuga wrote:
samuelroy21 wrote:
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 Smile


While you're at it, will you also add support for sprites of a size greater than 256x256?
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3 ... 11, 12, 13 ... 15, 16, 17  Next
» View previous topic :: View next topic  
Page 12 of 17
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement