Loading graphics via GD API

[OVERRiDE]

Hi Guys, 

 

I've just upgraded to JagStudio 1.11 and am really curious to see what is possible when unleashing the GD filesystem - in theory this can give us virtually unlimited storage space for our games, assuming we are going the digital-only route.

 

Anyway, I have tested the existing demo project "jaguargd" and I noticed that it is not correctly displaying the sample graphic when you press 4 on the dpad - instead, its rendering a brown image, as if the file content is not being read correctly.  I have the sample file "!LOGO.JAG" at the root of the SD card filesystem.  My SD card is flashed to the most recent bios version which is compliant with the documented version requirements.

 

I've done some further testing with text files, and can confirm that the files are being read from the SD card into RAM correctly, so the paths and pointers are correct.  But when I try to load with my own sample graphics ( which have been converted to *bmp.gfxdata ), I am getting the same issue as the sample project - just a brown texture.

So curious to hear any feedback, or if anyone else can confirm that the sample project is working correctly for them.

[Sporadic]

Someone else did mention a similar issue in testing, but we couldn't replicate it.

 

The jaguargd example works fine on my setup.

 

Could you PM me a zip file of your own test project (not the jaguargd example) and I could try that on my GD.

 

Then we can try and figure out what's happening.

 

Cheers.

[OVERRiDE]

Ok so I've been able to isolate this problem, and it is even occurring in the Raptor API example "EX-16 - Jaguar GD Functions", so it seems this is actually an issue with Raptor API GD functionality.

 

There are two ways to run your program on the GameDrive, one method is working and the other is not:

1. If you upload the program over USB via jaggd.exe, everything works correctly.  I am able to copy any file type ( text, graphics, sound ) into RAM or ROM and can confirm the file content is correct.
2. If you copy your program to the SD card and then launch it via the JagGD menu, File Reading is corrupted and GFX are not loading into RAM ( or ROM ) correctly

 

I am assuming there is some GD re-initialization that needs to occur to get things to work when you launch from the GD menu.  I've tried calling rapGDReset(GD_RESET_NORMAL) at the start of the code, but this seems to reset the entire hardware, not just the GD ( I was assuming our program would remain running in RAM, but this does not seem to be the case ) and the result is just an infinite loop of resetting lol.  So I'm not exactly sure how this reset function is intended to be used.

 

And one last note, which indicates that perhaps there is another issue at play, is text files seem to work just fine in both scenarios.  So text files (ascii) work fine, but binary files do not work in the 2nd scenario ( and most critical scenario ).  Perhaps the encoding is not being preserved, but why only in the 2nd sceario is beyond me.

Extract this archive to the root of your SD card then launch gd.rom from the GD menu.  The text file can be loaded correctly, but the GFX and Music will not.  Next, upload the gd.rom via jaggd.exe and everything works.

gd-test.rar

Edited April 18 by OVERRiDE

[+CyranoJ]

I have confirmed this and let SainT know.

[OVERRiDE]

Thanks @CyranoJ.  Really hoping this can be patched ( via GD Firmware update or Raptor API ) as the GDFS is basically useless currently, but has so much potential for increased storage space for digital releases

 

Another question I have is regarding the speed of file reads - in my rough profiling, we are getting less than 1MB/sec - is this expected?  If so, is this an inherent limit of the GDFS, or is there any room for API optimization? Its hard to believe commercial CD games with FMV are not exceeding this bitrate and they don't seem to have any issues running directly from the GD (granted, when running this way they are not using the File System in the traditional sense, so there may be much less overhead ).  I was thinking it would be cool to implement an FMV format similar to MJPEG using the Jags native image format, but with current bitrate throughput I can only squeeze like 3FPS with 240x240 resolution with current API / Firmware, so that is a no-go lol.

Edited April 25 by OVERRiDE

[Zerosquare]

15 minutes ago, OVERRiDE said:

Its hard to believe commercial CD games with FMV are not exceeding this bitrate

The best you can get with the JagCD is about 350 kB/sec, as it's a 2x CD drive. And that's under ideal conditions.