Page 1 of 1


PostPosted: 29 Mar 2019, 23:44
by lm
Is anyone using TinyGL or one of the various TinyGL forks (such as PicoGL, TinySDGL, etc.) as a backend for their game or program development? Also wondering if anyone's run across any interesting games written to work with TinyGL or one of its forks.

I'm considering using PicoGL as a backend for some programs I'm porting. It's missing some features of OpenGL, but I've been adding some in as needed. The version of PicoGL I'm working with now has limited support for glTexSubImage2D, can work with power of 2 sized textures that are represented with sizes other than 256 internally, has blending and some other features missing in TinyGL. If anyone else has added features, fixed bugs or patched TinyGL or a related fork, would love to compare notes on development changes.

PicoGL has an internal format of 32 bit ARGB. I've been debating whether to leave it using the ARGB format or whether I should convert it to another format such as RGBA. Are there any pros and cons to one particular 32 bit format over another?

Re: TinyGL/PicoGL

PostPosted: 30 Mar 2019, 01:05
by dulsi
Never heard of them. Do you have links? I found TinyGL but didn't find PicoGL in a quick search.

Why use them over OpenGL? If you need them for a minimal system, I don't understand why you would be looking to add support for things from OpenGL. Sort of like asking to attach a sail to a row boat instead of using the sail boat sitting next to it. I just don't see a reason why you would care if the format in ARGB or RGBA. Converting your data to the existing format has to be easier than modifying the library to support a different format. Certain things might certain make sense to add but a different internal format for color seems like a waste of time.

Re: TinyGL/PicoGL

PostPosted: 02 Apr 2019, 17:44
by lm
Sounds like it was assumed that I'm using TinyGL in place of OpenGL. I never said anything about not using OpenGL on platforms that support it. I write cross-platform software and need to port applications to some systems where OpenGL or Mesa are not options. I don't need full OpenGL support, but just enough support to get the applications working. Surprised more people haven't run across TinyGL. I've seen it used as a backend with some interesting gaming libraries. As to color formats, it's a 2 line change in the code to switch formats. I was more interested in whether a specific format would work better with particular hardware, GPUs, etc. I've seen some posts in forums that indicate people have noticed a difference in rendering time with certain hardware based on the format the graphics data was in. I can test on the hardware I have, but I can't test what works best for hardware I don't have access to.

Re: TinyGL/PicoGL

PostPosted: 02 Apr 2019, 19:04
by dulsi
I didn't assume you were using TinyGL in place of OpenGL. I assumed OpenGL wasn't available but you didn't say what platform you are using. I don't know what systems people use TinyGL or PicoGL on. The website I found says TinyGL was written in 1997 and the website was last updated in 2002. My initial thought for changes like this is that it isn't supported for a reason. But given how old the software is, the system you are using may have advanced and be perfectly capable for all I know. I'd suggest giving more information on the hardware you are using and what other hardware you would like to support plus a link to PicoGL. (Granted I probably can't help either way as I don't have a lot of experience with small systems or OpenGL but maybe someone here can.)

It does make me wonder if PicoGL or TinyGL could work on PocketArcade/TinyArcade.

Re: TinyGL/PicoGL

PostPosted: 07 Apr 2019, 07:36
by drummyfish
Thank you for sharing TinyGL, this is the first time I hear about this.

I have started my own very similar project, which is currently inactive, but planed to be worked on again very soon. It is a SW rasterization-based renderer, similar to OpenGL, but with different API. It will differ from TinyGL and other renderers in these:

- Integer arithmetic only, no floats whatsoever. This is to allow running it on the tiniest embedded devices like Gamebuino, which usually have a slow SW float emulation at best.
- Memory efficiency as much as possible while keeping speed, again for small devices.
- CC0 licensed for extreme simplicity of use. (It is also shame that humanity doesn't have basic things in public domain, like a freaking renderer. I wanna change that.)
- Single header in C running as C++ as well, again for extreme simplicity of use.
- Keep flexibility and independence with a fragment shader like function, which is linked at compile time to keep extreme speed.
- No dependencies whatsoever... not even standard library, since some embedded devices may have limited support for it.

It is named Small3DLib and is basically going to be a continuation of my completed raycasting library that works this way already:

I've already made it render some stuff on a small gaming console Pokitto:



Sorry for this shameless ad :)