
Thank you a lot for releasing this library, and I'm really happy to see that it has been included in KOS repository!
Dreamcast isn't dead, my friends

Nice. That was done thanks to our conversations prompting me to do sobogglez wrote:I like that you replaced custom functions with standard ones.
bogglez wrote:Why does get active texture always return 0?
Code: Select all
GL_ACTIVE_TEXTURE
params returns a single value indicating the active multitexture unit. The initial value is GL_TEXTURE0. See glActiveTexture.
I think you're confused about what this function does?PH3NOM wrote:bogglez wrote:Why does get active texture always return 0?Problem is, the PVR does not support multi-texture in hardware.Code: Select all
GL_ACTIVE_TEXTURE params returns a single value indicating the active multitexture unit. The initial value is GL_TEXTURE0. See glActiveTexture.
Basically, that means we need to transform/submit every vertex multiple times, i.e. once per enabled texture unit.
I had minimized the burden on the CPU by only transforming each vertex once, but then submitting multiple times to the PVR ( each with their own u/v set ).
However, I realized some problems with my old multi-texture code, specifically when NearZ Clipping is enabled.
Because of that, in this build, the old multi-texture code has been removed, and so have the examples using it.
When I get some time, one of my top priorities for the API is working out a proper multi texture unit implementation.
If you have any ideas on the implementation, as always, let me know!
So all you have to do in glGet is to return the argument of the last glActiveTexture call. This is a bug. Not that glGet for the active texture is useful or anything..glActiveTexture selects which texture unit subsequent texture state calls will affect.
Code: Select all
Multitexture
Modern OpenGL hardware implementations support the capability to apply two or more textures to geometry simultaneously. If an implementation supports more than one texture unit, you can query with GL_MAX_TEXTURE_UNITS to see how many texture units are available:
Code: Select all
/home/jaerder/development/Tools/dreamcast/kallistios/utils/bin2o/bin2o romdisk.img romdisk romdisk.o
kos-cc -o bin/main.elf bin/asset_loader.o bin/data_estructures.o bin/dc_render.o bin/fnt_parser.o bin/loading_screen.o bin/main.o bin/matrix.o bin/obj_loader.o bin/pcx_loader.o bin/png_loader.o bin/procedural.o bin/xml_parser.o romdisk.o -L/home/jaerder/development/Tools/dreamcast/kallistios/lib -lgl -lpcx -lkosutils -lexpat -lpng -lz -lm -Wl,--start-group -lkallisti -lc -lgcc -Wl,--end-group
bin/dc_render.o: In function `InitRenderTexture':
/home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/dc_render.c:128: undefined reference to `_glKosTexImage2D'
bin/pcx_loader.o: In function `loadtxr':
/home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/pcx_loader.c:32: undefined reference to `_glKosTexImage2D'
bin/png_loader.o: In function `loadpng':
/home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/png_loader.c:29: undefined reference to `_glKosTexImage2D'
collect2: error: ld returned 1 exit status
make: *** [bin/main.elf] Error 1
It has been removed. There's no need for it, since you can do the same thing with standard OpenGL's framebuffer objects which have been added with this release.Jae686 wrote:Good Afternoon.
I've checked out the latest version of the API, but now I get the following error :What happened to the glKosTexImage2D function?Code: Select all
/home/jaerder/development/Tools/dreamcast/kallistios/utils/bin2o/bin2o romdisk.img romdisk romdisk.o kos-cc -o bin/main.elf bin/asset_loader.o bin/data_estructures.o bin/dc_render.o bin/fnt_parser.o bin/loading_screen.o bin/main.o bin/matrix.o bin/obj_loader.o bin/pcx_loader.o bin/png_loader.o bin/procedural.o bin/xml_parser.o romdisk.o -L/home/jaerder/development/Tools/dreamcast/kallistios/lib -lgl -lpcx -lkosutils -lexpat -lpng -lz -lm -Wl,--start-group -lkallisti -lc -lgcc -Wl,--end-group bin/dc_render.o: In function `InitRenderTexture': /home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/dc_render.c:128: undefined reference to `_glKosTexImage2D' bin/pcx_loader.o: In function `loadtxr': /home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/pcx_loader.c:32: undefined reference to `_glKosTexImage2D' bin/png_loader.o: In function `loadpng': /home/jaerder/development/Projectos Software/vidfdc/dreamcast/src/png_loader.c:29: undefined reference to `_glKosTexImage2D' collect2: error: ld returned 1 exit status make: *** [bin/main.elf] Error 1
Hey Gyro hope things are on track for u guys.GyroVorbis wrote:We just got back from SIEGECon promoting Elysian Shadows, and I want you to know that we pushed the SHIT out of this GL API for Dreamcast. Got QUITE A FEW developers very interested in developing for DC, and this is pretty much a dream come true for them... Carry on the good fight!
Are you sure your idea would work? I don't see how you compute the q component in your proposed approach?When the four texture coordinates (s, t, r, q) are multiplied by the texture matrix, the resulting vector (s' t' r' q') is interpreted as homogeneous texture coordinates. In other words, the texture map is indexed by s'/q' and t'/q' . (Remember that r'/q' is ignored in standard OpenGL, but may be used by implementations that support a 3D texture extension.)
Please make it use malloc instead, as soon as possible. That will certainly overflow the stack on any relatively large texture on anything but the main thread. That will not only cause stack related problems, but will also cause heap problems (since thread stacks are allocated with malloc, so they're on the heap too).PH3NOM wrote:5. Didn't think that would be a problem, but it would be easy enough to malloc() instead...
Keep me postedPH3NOM wrote: 3. The DMA Vertex Transfer is still experimental, and thus disabled by default.
The current implementation is using blocking DMA and shows faster throughput on emulator, but is not working on real hardware.
I would like to enable non-blocking DMA transfers for the Multi-Texture Pass, as it should be possible to be setting the next texture units multi u/v cords on the CPU while the DMA simultaneously transfers current texture unit's vertex buffer.
Hm, you're right, it would only work with particular matrices without translation and projection.. sorry about that.PH3NOM wrote: 4. Texture coordinates, even 2D, are still transformed as a 4D vector, from the redbook:Are you sure your idea would work? I don't see how you compute the q component in your proposed approach?When the four texture coordinates (s, t, r, q) are multiplied by the texture matrix, the resulting vector (s' t' r' q') is interpreted as homogeneous texture coordinates. In other words, the texture map is indexed by s'/q' and t'/q' . (Remember that r'/q' is ignored in standard OpenGL, but may be used by implementations that support a 3D texture extension.)