nglVideo - an alternative to videoGL (update 2/17/11)

[Discostew]

(2/17/11)

Now that nglVideo has been integrated into libnds, these separate libraries are no longer needed. The ability to choose to have textures be manually allocated (by when the texture was ready to be copied) was not included, as it not only wasn't something openGL would do (since I wanted this to approximate it), but it also bloated the code a little and forced more processing for very little benefit, if any. Everything else is included.

I'll keep the original post here as a reference.

-----------------------------------------------------------------------------

(1/5/11)
(By request, the source is now available)

Some of you may remember me sending in a modified version of the videoGL.c file to the devkitPro team for review, which included a few bug fixes and my own version of dynamic texture allocation. Well, my brain began spinning once again, and I tried my hand again at an alternative to the videoGL functionality.

What came about from this is the nglVideo library, a separate set of functions which contains most of the functions that videoGL contained, removing some here and adding some there. So, what does this library do that videoGL does not?

- Texture AND texture palette dynamic allocation
- Allocation based on current state of video banks (if a video bank is not allocated to textures or texture palettes, the allocator ignores that bank and moves to the next one)
- Textures can be deleted, so no need to always reset the entire system.
- ALL DS-native formats supported, including GL_COMPRESSED
- Textures can be directly sent to video memory (GL_COMPRESSED textures automatically do), or can be in main memory in preparation for use in video memory when they are needed (manually called atm, but perhaps a change to dynamically later on)

I would consider this an alpha version, because there are still a few things that need to be done, such as if vram banks are not in sequential order (like VRAM_B takes up slot0 and VRAM_A takes slot1).

I've supplied the library and an example below. The functions called, for the most part, have an 'n' appended to the start of the functions, to differentiate themselves from their videoGL counterparts. As for the rest of the gl-like functions found in video.h, they can be used in conjunction with nglVideo because they do not have any direct association with functions in videoGL.


Library [Mirror]
Example [Mirror]

Source [Mirror]

The example project included is basically the Palette Cube example in libnds, but the functions are changed, and it also includes the compressed texture made by kusma (credit goes to him for that and his texture converter that generated the texture).

Note: When using GL_COMPRESSED textures, if the texture 'tiles' and 'header' are separate files, then they need to be combined together, the 'tiles' first, then the 'header', before using the call nglTexImage2D. Also, it is best to load the GL_COMPRESSED texture first unless you do manual video bank assigning to prevent the allocator from using certain banks when loading normal textures first, because if VRAM_B doesn't have enough space or if VRAM_A and VRAM_C don't have enough space, the compressed textures won't be loaded up.

[elhobbs]

are you going to release the source code?

[Discostew]

Yeah, but first I need to put in commenting, as it practically contains none. It's one of my bad habits while I program, since I usually understand how it works, so I don't spent time making those comments as I immediately move on to the next section after I finish one.

One thing I would like to know is opinions from those that have tried it. Feedback always helps me want to continue adding more things or optimizing existing code when possible.

[elhobbs]

I think in this case the source code would be more helpfull than not.

I am curious as to how you are saving textures in main memory. is the memory managed by the user or by the library? at which point are they loaded to vram?

[Discostew]

Sorry, I meant for the source to get released, but not only have I been busy, but after having looked at the code, there are possible memory leaks, which I am attempting to clean up in my free time.

As for your questions...
Atm, unless a texture is of GL_COMPRESSED type, the texture data is copied to main memory, and must be copied to VRAM manually by the function nglCopyTextureToVRAM. So, there becomes 2 possible spaces for textures; one in main memory and one in vram (compressed textures have no space in main memory, but have two spaces in vram because it is required). One of my plans in the future (hopefully near future) is to allow normal textures the same treatment as compressed ones, in that they don't get stored in main memory (meaning they won't take up space there), but are automatically placed in VRAM, and can't be removed except by deleting the texture name or replacing the texture under the same texture name.

As far as memory is managed, it is kind of a joint management system with the user and the library. The user specifies which "non-compressed" textures get placed into VRAM and when they get placed. The library handle the allocation, deallocation, placement, etc based on what the user specifies.

[WinterMute]

How about, rather than writing an entirely new library, you look at contributing your code to libnds? It sounds like at least some of your nGL functions are direct replacements to those in videoGL.c. There's definitely some room for cleanup and improvement in our code.

Sorry I haven't got around to looking at your patch, been quite busy of late rebuilding the site & looking after the latest addition to our family. Is that patch still relevant given all the extra work you've put in recently?

[Discostew]

Well wintermute, one reason why I went along with this library was because I never heard back about the patch. People are busy, I know, so I figured that I might as well, for the time being, create a separate library that handled the same thing and didn't interfere with the current videoGL stuff, but one thing led to another, and it became an upgraded library, packed with what the prior one did, but done differently, and added stuff like palette allocation and gave way for using GL_COMPRESSED textures.

The old patch is somewhat different compared to this new library. That old one relied on an array bitmask, in that each bit in each element of the array represented a block of memory in the overall section, where those that are filled represent "used" blocks. A layout, if you will, of the memory it is designated to, so searching for "empty" space was easy. It was a nice idea, but with this new library, I changed it to a dual doubly-linked list (one that is linked linearly to each other, and the other linked to the next/prior filled/empty block). A bit more code and data used than the last, but without all the extraneous loopings from the prior coding that was potentially slower.

I'm currently in the process of optimizing some routines because it had to continually (de)allocate when switching bound textures that weren't currently in video memory (since it needs to have a spot ready in case the texture is set/copied to it). What I will do is finish the commenting (as I said I would), and release the source prior to my work on optimizing (because it is broken right now because of it).

[ShotgunNinja]

Argh... My college has blocked MediaFire because of people pirating stuff via file-sharing sites. Any chance of letting me export the SVN or whatever else you use once the fixes are done? I really want to see how you manage the VRAM bank selection and texture palette allocation, as I've been trying to come up with a good system for doing that on my own at this point.

[azenris]

Hi discostew, does your glDeleteTextures work? I tried it and end up with crashes. If you successfully used it I guess I have to look harder at my code. I noticed you didn't use it in your examples. Just thought Id ask

[azenris]

I tried to integrate it into libnds, but didn't turn out perfectly :p

I made some changes, mostly noted with "//NOTE: "

Would be imba if you commented more on your mem block code.

I think glDeleteTextures isn't working, well, tbh Im not overly sure. Guess it needs more tests.

I also added 2 functions. One to preload palettes without an attached texture, and one to switch palettes on textures with the option to delete the older one.

Anyway, I tried, sorry I couldn't get it fully working

http://www.filefront.com/17726610/videogl.zip