Jump to content
IGNORED

Loading graphics via GD API


OVERRiDE

Recommended Posts

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.

image.thumb.png.c2b444e21042be5430d94d08cf5d35a1.png

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by OVERRiDE
Link to comment
Share on other sites

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 by OVERRiDE
Link to comment
Share on other sites

  • 3 months later...
  • 4 months later...
  • 3 months later...

Ok, figured out what's going on, the GDBIOS is not being correctly initialised from Raptor. Not sure why yet. The bindings on GitHub call GD_Init on installing the GDBIOS. The test ROM above is not doing this. The only thing the init function does currently is to map the FIFO block into memory so it can be read directly for faster data transfers, which is why the data coming in is junk (or just FF in this case) when running from ROM. When running via USB upload it jumps to the code directly and the FIFO is still mapped in. The reason small files worked is that for transfers less than 32 bytes it does a byte by byte copy from the serial FIFO register rather than using the memory mapped FIFO. I'll liaise with @CyranoJ to get this fixed.

Edited by SainT
  • Like 4
  • Thanks 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...