Game browser with GEM/SDL xbios targets using gcc

C and PASCAL (or any other high-level languages) in here please

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Game browser with GEM/SDL xbios targets using gcc

Postby MegatronUK » Fri Jan 04, 2019 11:29 am

Edit: Title changed to reflect that this is now both an SDL or GEM application and works with either backend

Hi everyone,

I'm playing around with Vincent Rivière's m68k set of GCC tools, including the port of SDL. I know, I know, it's very limited in xbios mode on an ST (16 colour greyscale according to the docs) and slow, but I'm just wanting to try a few things.

However, I'm not having any luck at all getting anything displayed.

I'm using Hatari, configured as a vanilla ST, and no matter what I do, whether it's trying to display a bitmap, or render a simple flat rectangle it doesn't work. The behaviour I see is SDL initialises the screen (320x200x8), it goes black, then whatever I try to blit to the screen gets at most, shown as a 1 pixel line at the top of the screen - even if all I'm doing is filling the entire screen with white as follows:

Code: Select all

#include <stdio.h>
#include <unistd.h>
#include <SDL/SDL.h>

SDL_version compiled;
SDL_version linked;
int main(int argc, char* argv[]){
   
   SDL_Surface *bg;
   SDL_Surface *image;
   SDL_Surface *bmp;
   SDL_Surface *display;
   SDL_Rect src, dest;
   char vdriver[32];
   FILE *log;   
   
   SDL_VERSION(&compiled);
   
   log = fopen("MENU.LOG","w");

   fprintf(log, "Menu tool running\n");
   fprintf(log, "-----------------\n");
   fprintf(log, "\n");
   fprintf(log, "libSDL: Initialising...\n");
   fflush(log);
   
   if (SDL_Init(SDL_INIT_VIDEO) != 0){
      // Error occurred loading SDL
      fprintf(log, "SDL_Init Error: %s\n", SDL_GetError());
      fflush(log);
      fclose(log);
      sleep(2);
      exit(-1);
   } else {
      
      fprintf(log, "libSDL: Initialised v%d.%d.%d ok!\n", compiled.major, compiled.minor, compiled.patch);
      fflush(log);
      
      // Set display mode for the SDL screen
      fprintf(log, "Display: Driver loading...\n");
      fflush(log);
      display = SDL_SetVideoMode(320, 200, 0, SDL_SWSURFACE);
      if(display == NULL){
         fprintf(log, "SDL_SetVideoMode Error: %s\n", SDL_GetError());
         fflush(log);
         SDL_Quit();
         fclose(log);
         sleep(2);
         exit(-1);
      } else {
         fprintf(log, "Display: Driver %s ok!\n", SDL_VideoDriverName(vdriver, 32));
         fprintf(log, "Display: Driver mode %dx%dx%dbpp ok!\n", display->w, display->h, display->format->BitsPerPixel);
         fflush(log);
      }
      
      // Load splash bitmap
      fprintf(log, "Bitmap: Loading...\n");
      fflush(log);
      bmp = SDL_LoadBMP("C:\\COMPILER\\MENU\\LOGO.BMP");
      if (bmp == NULL){
         fprintf(log, "SDL_LoadBMP Error: %s\n", SDL_GetError());
         fflush(log);
         SDL_Quit();
         fclose(log);
         sleep(2);
         exit(-1);
      } else {
         fprintf(log, "Bitmap: Loaded %dx%dx%dbpp ok!\n", bmp->w, bmp->h, bmp->format->BitsPerPixel);
         fflush(log);
         bg = SDL_DisplayFormat(bmp);
         SDL_FreeSurface(bmp);
      }
      
      // Fill screen white
      fprintf(log, "Box: Drawing...\n");
      SDL_FillRect(display, NULL, 0xFFFFFF);
      SDL_Flip(display);
      fprintf(log, "Box: Drawn\n");
      fflush(log);
      
      // Display bitmap on screen
      image = SDL_DisplayFormat(bg);
      SDL_FreeSurface(bg);
      fprintf(log, "Display: Blitting...\n");
      fflush(log);
      
      //Construct the source rectangle for our blit
        src.x = 0;
        src.y = 0;
        src.w = image->w;    //Use image->w to display the entire width of the image
        src.h = image->h;    //Use image->h to display the entire height of the image

        //Construct the destination rectangle for our blit
        dest.x = 140;       
        dest.y = 0;
        dest.w = image->w;    //Ensure the destination is large enough for the image's entire width/height
        dest.h = image->h;
      
      SDL_BlitSurface(image, NULL, display, &dest);
      SDL_Flip(display);
      fprintf(log, "Display: Blitted ok!\n");
      fflush(log);
      SDL_Delay(3000);
      SDL_FreeSurface(image);
      fprintf(log, "Bitmap: Freed\n");
      fflush(log);
   }
   fprintf(log, "libSDL: Unloading...\n");
   fflush(log);
   SDL_Quit();
   fprintf(log, "libSDL: ok\n");
   fflush(log);
   fclose(log);
   sleep(2);
   return 0;
}


My log file indicates everything proceeds okay, but the white box renders as a single pixel white line at the top of the screen, as does the bitmap image:

sdl.jpg


The output I'm writing to the log shows no errors:

Code: Select all

Menu tool running
-----------------

libSDL: Initialising...
libSDL: Initialised v1.2.15 ok!
Display: Driver loading...
Display: Driver xbios ok!
Display: Driver mode 320x200x8bpp ok!
Bitmap: Loading...
Bitmap: Loaded 180x135x8bpp ok!
Box: Drawing...
Box: Drawn
Display: Blitting...
Display: Blitted ok!
Bitmap: Freed
libSDL: Unloading...
libSDL: ok


I suppose most people (if any) have used SDL in GEM, but did anyone come across this behaviour?
You do not have the required permissions to view the files attached to this post.
Last edited by MegatronUK on Thu Jan 31, 2019 8:47 pm, edited 1 time in total.

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: SDL xbios target using gcc

Postby MegatronUK » Thu Jan 10, 2019 9:31 pm

I can replicate the error with a basic SDL_Fillrect() command:

Code: Select all

SDL_Init(SDL_INIT_VIDEO);
display = SDL_SetVideoMode(320, 200, 0, SDL_SWSURFACE|SDL_FULLSCREEN);
for(i=0;i<256;i++){
      colors[i].r=i;
      colors[i].g=i;
      colors[i].b=i;
   }
SDL_SetColors(display, colors, 0, 256);
box.x = 100;
box.y = 100;
box.w = 90;
box.h = 90;
SDL_FillRect(display, &box, SDL_MapRGB(display->format, 0xFF, 0xFF, 0xFF));
SDL_Flip(display);
SDL_Delay(5000);


The above extract should draw a white box of 90x90 pixels at 100,100 - it instead does this:

grab0022.png


Changing the x coordinates to 0 does this:

grab0053.png


It appears that x coordinates are being honoured, but the base value for y coordinates is off the top of the display, hence everything I draw I only ever see the last line of pixels; so my bitmap is probably being correctly displayed in glorious greyscale, but I just cannot see it :D

I've passed the info on to Patrice to see if he has any ideas. I've also updated to Hatari 2.1.0 to see if it was something to do with video support that perhaps was fixed between the version I was using on Ubuntu 16.04 LTS (Hatari 1.8.0) and the current release, sadly it seems not.

John
You do not have the required permissions to view the files attached to this post.

jury
Captain Atari
Captain Atari
Posts: 376
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: SDL xbios target using gcc

Postby jury » Fri Jan 11, 2019 4:57 am

MegatronUK wrote:I'm using Hatari, configured as a vanilla ST, and no matter what I do, whether it's trying to display a bitmap, or render a simple flat rectangle it doesn't work. The behaviour I see is SDL initialises the screen (320x200x8)

The output I'm writing to the log shows no errors:

Code: Select all

...
Display: Driver mode 320x200x8bpp ok!



Are you sure you have configured Hatari correctly? ST surely do not have ( unfortunately :) ) 8 bpp modes. It shoud show 4bpp.
So maybe its a problem with wrong configuration.

MegatronUK wrote:

Code: Select all

   
      // Display bitmap on screen
      image = SDL_DisplayFormat(bg);



This is definitely redundant, especially that you try to run it on ST, which has quite limited power for SDL stuff. You can blit to display directly from bg structure, or load ( and do sdl_displayformat ) directly to image structure.

jury
Captain Atari
Captain Atari
Posts: 376
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: SDL xbios target using gcc

Postby jury » Fri Jan 11, 2019 6:45 am

OK, done some quick test on Falcon and it seems all is fine as seen on the attached screen.
So its either Hatari related ( like wrong configuration ) or implementation of SDL for ST is rather not proper, especially, that SDLs target is definitely not ST.
You do not have the required permissions to view the files attached to this post.

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: SDL xbios target using gcc

Postby MegatronUK » Fri Jan 11, 2019 8:25 am

Hi, unfortunately SDL won't initialise with an SDL screen set to 4bit:

Code: Select all

display = SDL_SetVideoMode(320, 200, 4, SDL_SWSURFACE|SDL_FULLSCREEN);


This raises an SDL_Error message of:

Code: Select all

Invalid bits per pixel (range is {8...32})


I definitely have Hatari configured to 16 colour mode. Basic ST emulation mode, no blitter, 8MHz, 16 color, local filesystem mapped to a GEMDOS drive. Other than that, it hasn't had any further tweaking. I've tried different TOS versions (and EmuTOS) to see if it makes a difference and nothing.

The display depth doesn't appear to have any impact - I can draw a box and fill it with any colour and it gets converted down to a relevant greyscale mode (although I of course only ever see the bottom row of pixels). For example, I can see differences between doing a SDL_Fillrect(,, 0xFF, 0x00, 0x00) or SDL_Fillrect(,, 0x00, 0xFF, 0x00) or SDL_Fillrect(,, 0x00, 0x00, 0xFF).

Of course, this could simply be a Hatari emulation issue, but I don't have a real ST to test with at the moment.

jury
Captain Atari
Captain Atari
Posts: 376
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: SDL xbios target using gcc

Postby jury » Sat Jan 12, 2019 2:52 pm

MegatronUK wrote:Hi, unfortunately SDL won't initialise with an SDL screen set to 4bit:

Code: Select all

display = SDL_SetVideoMode(320, 200, 4, SDL_SWSURFACE|SDL_FULLSCREEN);


This raises an SDL_Error message of:

Code: Select all

Invalid bits per pixel (range is {8...32})



Have you tried to set SDL_VIDEODRIVER to xbios? If not, do so and then run the code. From what I understand, GEM video driver ( and I guess thats the one you are using ) works only for 8bpp or higher and with xbios one 4bpp can be set.

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: SDL xbios target using gcc

Postby MegatronUK » Sat Jan 12, 2019 3:48 pm

With no SDL_VIDEODRIVER environment variable set it defaults to xbios - the code...

Code: Select all

fprintf(log, "Display: Driver %s ok!\n", SDL_VideoDriverName(vdriver, 32));

...correctly prints that xbios mode is in use.

I reported my findings to Patrice and he's been looking at it as well - he thinks that there may be some regressions with the back end Atari-specific chunky to planar video routines in libSDL; as the same "everything draws on line 0" display issues occur for him as well when he tried one of the example SDL routines.

I have my fingers crossed that he can solve it!

I've also just bought myself a 520 STE so that in the future I can check on real hardware. For now I'm continuing to develop on Linux+X11 and Cygwin so I can still progress things... I'm aiming to have a game browser/launcher tool like iGame for WHDLoad games on the Amiga.

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: SDL xbios target using gcc

Postby MegatronUK » Sun Jan 13, 2019 11:58 pm

Patrice has released a new version of libSDL 1.2.15 to resolve the regression in the c2p routine, as well as a few other enhancements. You can find it on his webpage.

It has certainly fixed my display problems:

grab0003.png


I am rather happy :D

Yes, it's certainly not fast, but it works.

Now I need to put some effort into speeding this thing up... scanning an emulated ST hard drive shows that this thing won't be practical in real use... scan and save to CSV is probably the way to go, then reload the CSV the next time around.

I'm also not using SDL_ttf for text output - because it results in an absolutely massive binary (pulls in libpng, bz2, libz and more), so have put together a lightweight bitmap to font routine instead (still working the kinks out!) that has no other dependencies than libSDL itself.
You do not have the required permissions to view the files attached to this post.

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: SDL xbios target using gcc

Postby MegatronUK » Mon Jan 14, 2019 12:16 am

And with text now showing...

grab0004.png


List of scanned games shown in browser window, game thumbnails or folder bitmaps shown on the right and detected .TOS/.PRG files for that game, plus any README files in that games folder (ultimately will be able to view the text file before launching the game - by one of the detected binaries).

I'm writing it to work best with collections of HD-compatible games, like the ones ppera has done (it's so nice having all the .TOS and .TXT files named consistently, though I scan for any that match those extensions).

Lots of optimization now to do! As scrolling between games causes a delay of about 2-3 seconds now! :coffe:
You do not have the required permissions to view the files attached to this post.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1995
Joined: Sun Jul 31, 2011 1:11 pm

Re: SDL xbios target using gcc

Postby Eero Tamminen » Thu Jan 17, 2019 11:42 pm

Remember that Hatari debugger includes a profiler:
https://hg.tuxfamily.org/mercurialroot/ ... #Profiling

It can provide for example timing annotated disassembly, and call, instruction & cycle count callgraphs. For 68000 emulation, the information is cycle-accurate.

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: SDL xbios target using gcc

Postby MegatronUK » Sun Jan 27, 2019 9:58 pm

Looks like I've about hit the limit of SDL performance on the ST(E)... moving between game entries and loading the 180x135px bitmap from disk (and then blitting to screen) won't get any faster than around 2s. Hatari confirms the top callers by symbol as:

Code: Select all

> profile symbols 10
addr:      count:      symbol:
0x046986    0.65%   64000   c2p4_bcl07   moveq     #0,d0
0x0469a4    0.65%   64000   c2p4_bcl815   moveq     #0,d0
0x03208e    0.63%   61904   _SDL_GetTicks   movem.l   d2-d4/a2,-(sp)
0x046982    0.08%   8000   c2p4_bclx   moveq     #0,d1
0x052726    0.07%   6549   ___mulsi3   move.w    4(sp),d0
0x045e4c    0.02%   1642   _SDL_AtariMint_BackgroundTasks   jsr       $48e80
0x048e80    0.02%   1642   _SDL_AtariMint_UpdateAudio   move.l    a3,-(sp)
0x05eefa    0.01%   1316   _memset   movea.l   4(sp),a0
0x05ecb6    0.01%   628   _memcpy   movea.l   4(sp),a1
0x060546    0.00%   419   _strlen   movea.l   4(sp),a0
10 CPU symbols listed.


That'll be the chunky to planar routines then! 16MHz mode makes it more bearable, but I don't have that in the real world :)

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: SDL xbios target using gcc

Postby MegatronUK » Sun Jan 27, 2019 10:19 pm

... and the hatari_profiler script confirms it:

Code: Select all

CPU profile information from 'menu-profile.txt':
- Hatari v2.1.0, WinUAE CPU core

Time spent in profile = 14.38483s.

Visits/calls:
- max = 125193, in __etext+15923306 at 0xfa0000, on line 6749
- 344247 in total
Executed instructions:
- max = 125193, in __etext+15923348 at 0xfa002a, on line 6749
- 9783154 in total
Used cycles:
- max = 3232966, in __etext+15923356 at 0xfa0032, on line 6753
- 115384304 in total

Visits/calls:
  36.37%      125193   CARTRIDGE
  18.59%       63982   c2p4_bcl815
  18.58%       63978   c2p4_bcl07
  17.98%       61885   _SDL_GetTicks
   2.32%        7995   c2p4_bclx
   1.90%        6547   ___mulsi3

Executed instructions:
  30.83%     3016304   _BlitNto1
  26.77%     2618874   ROM_TOS
  12.02%     1176190   _SDL_GetTicks
   6.39%      624897   CARTRIDGE
   4.99%      488000   c2p4_bcl07
   4.91%      480800   c2p4_bcl815
   4.48%      438615   _SDL_Delay
   1.98%      194053   _text2surface
   1.21%      118788   _memset

Used cycles:
  26.67%    30773036   _BlitNto1
  26.40%    30456832   ROM_TOS
  16.56%    19102432   _SDL_GetTicks
   6.93%     8001356   CARTRIDGE
   4.37%     5047180   c2p4_bcl815
   4.33%     5001172   c2p4_bcl07
   4.15%     4787704   _SDL_Delay
   1.53%     1766964   _text2surface
   1.49%     1722824   ___mulsi3
   1.48%     1709516   _memset


Virtually all of the time is spent in either the SDL BlitNto1() function (see src/video/SDL_blit_N.c) with the Atari-specific c2p4_* backend functions being next (see src/video/ataricommon/SDL_ataric2p.S).

Oh well! Next up is pulling SDL out and replacing it with something lighter - it's a shame it's so slow (though it's impressive it works at all), as I've got something that works lovely across at least three different platforms right now using the same display code.

mikro
Hardware Guru
Hardware Guru
Posts: 2035
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: SDL xbios target using gcc

Postby mikro » Mon Jan 28, 2019 1:08 pm

What about preprocessing the image(s) to copy? That way SDL wouldn't need to call the c2p routine every time. I'm pretty sure there is a raw blitting routine available.

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: SDL xbios target using gcc

Postby MegatronUK » Mon Jan 28, 2019 2:56 pm

Actually, being forced to do this isn't necessarily a bad thing. It's made me abstract out the graphics calls I'm using from libSDL and instead call a small shim library instead, and I'll swap in at compile time a lightweight wrapper around libSDL, Allegro or (probably) Godlib, depending on the platform.

Preprocessing images isn't a bad idea - I'm already doing so with imagemagik on Linux to get better greyscale images on the ST, but doing it in advance isn't going to work in every situation; for example, the ultimate idea with this application is to distribute it as a simple application.tos binary and have people drop it in to AUTO, and it will just work, with no external dependencies.

mikro
Hardware Guru
Hardware Guru
Posts: 2035
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: SDL xbios target using gcc

Postby mikro » Tue Jan 29, 2019 7:51 am

MegatronUK wrote:Preprocessing images isn't a bad idea - I'm already doing so with imagemagik on Linux to get better greyscale images on the ST, but doing it in advance isn't going to work in every situation; for example, the ultimate idea with this application is to distribute it as a simple application.tos binary and have people drop it in to AUTO, and it will just work, with no external dependencies.

You don't need any - on the first start you'd just chunky-to-planar copy your bitmap(s), store them in a folder and next time you need a bitmap to load / display, you'd use the c2p'ied one, instead the original.

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: SDL xbios target using gcc

Postby MegatronUK » Tue Jan 29, 2019 9:48 am

Not a bad idea; first start up will be slow, but caching them, I like that. Especially since having looked in to Godlib a bit (probably the best alternative), it seems that it's not trivial to get it to integrate with the rest of the gcc tools.

I can probably also do the same with the various UI elements, since they are also (effectively) bitmaps as SDL draws them.

The other alternative is to consider using a fullscreen VDI version of the application instead - at least the UI elements and text wouldn't all be bitmaps and subject to c2p as per libSDL, but I'm finding it a bit confusing to get started with any examples (even something as simple as initialising the library and blanking the screen).

mikro
Hardware Guru
Hardware Guru
Posts: 2035
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: SDL xbios target using gcc

Postby mikro » Wed Jan 30, 2019 8:05 am

MegatronUK wrote:The other alternative is to consider using a fullscreen VDI version of the application instead - at least the UI elements and text wouldn't all be bitmaps and subject to c2p as per libSDL, but I'm finding it a bit confusing to get started with any examples (even something as simple as initialising the library and blanking the screen).

Look at Tim Oren's Professional GEM: https://greblus.files.wordpress.com/201 ... of_gem.pdf, all I know about GEM and VDI is from this great tutorial. :)

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: SDL xbios target using gcc

Postby MegatronUK » Wed Jan 30, 2019 8:39 am

That's a great document - I've been trying to work from the "Compute! Atari ST Technical Reference part 1" and the "Atari Compendium" which are ok, but that looks more comprehensive. Last night I wrote a small shim that maps my existing draw box routine from SDL to VDI primitives. I need to look at font routines and bitmap loading and conversion next.

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: SDL xbios target using gcc

Postby MegatronUK » Wed Jan 30, 2019 2:50 pm

Well I have most of the graphics primitives (I mainly use simple boxes and 'drop shadows') in my application now using either SDL or VDI, depending on which is included at link time.

I also managed to figure out how to draw the whole thing in reverse video as per SDL, by swapping colour indices/pens 0 and 1. It took me a while to work out that I couldn't just set a fill or outline colour per drawing primitive!

Here's the same application running (no text or graphics yet) running with the VDI backend and same application calls:

vdi.png


Yes, it looks boring, but I'm pleased with myself that I've got the display code abstracted away enough that it just works.

Fonts next, I think... also, any tips to get rid of the flashing cursor at 0,0?
You do not have the required permissions to view the files attached to this post.

User avatar
rudis
Captain Atari
Captain Atari
Posts: 164
Joined: Mon Feb 14, 2011 9:41 am

Re: SDL xbios target using gcc

Postby rudis » Wed Jan 30, 2019 4:31 pm


MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: SDL xbios target using gcc

Postby MegatronUK » Wed Jan 30, 2019 4:59 pm

Text now showing - just the default fixed width system font for now - but it's not too bad a match to the LCD bitmap font I'm using in the SDL backend:

vdi_text.png


... and, of course since it isn't having to do a blit for each character, so it's substantially faster. So is the underlying call to v_bar() which is done either once or twice, depending on whether the box has a drop shadow or not. Doing the same in SDL required one more function call (it doesn't have a "draw rectangle outline" function, so needs two calls to SDL_FillRect for a plain box; one inner and one outer, and three calls for a drop shadow box; shadow box, outer, inner). So speed is much better all round so far.

Next is to abstract away the SDL input routines!
You do not have the required permissions to view the files attached to this post.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1995
Joined: Sun Jul 31, 2011 1:11 pm

Re: SDL xbios target using gcc

Postby Eero Tamminen » Thu Jan 31, 2019 8:47 pm

MegatronUK wrote:

Code: Select all

...
Used cycles:
  26.67%    30773036   _BlitNto1
  26.40%    30456832   ROM_TOS
  16.56%    19102432   _SDL_GetTicks
   6.93%     8001356   CARTRIDGE
   4.37%     5047180   c2p4_bcl815
   4.33%     5001172   c2p4_bcl07
   4.15%     4787704   _SDL_Delay
   1.53%     1766964   _text2surface
   1.49%     1722824   ___mulsi3
   1.48%     1709516   _memset



TOS, SDL_GetTicks() + SDL_Delay() and Cartridge code (for redirecting GEMDOS HD calls) taking over half of the time is quite suspicious:
* Why SDL timing code is running while you're drawing stuff?
* Did you trace what OS calls are done during drawing?

Or were you profiling also something else (user interaction) than just drawing?

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1995
Joined: Sun Jul 31, 2011 1:11 pm

Re: SDL xbios target using gcc

Postby Eero Tamminen » Thu Jan 31, 2019 8:49 pm

MegatronUK wrote:Text now showing - just the default fixed width system font for now - but it's not too bad a match to the LCD bitmap font I'm using in the SDL backend:

... and, of course since it isn't having to do a blit for each character, so it's substantially faster.


And if VDI is too slow, one can always accelerate it (a *lot*) with something like NVDI. :-)

MegatronUK
Atariator
Atariator
Posts: 23
Joined: Fri Jan 04, 2019 11:11 am

Re: Game browser with GEM/SDL xbios targets using gcc

Postby MegatronUK » Thu Jan 31, 2019 9:03 pm

I have (had) an SDL_Delay() of 200ms after my screen redraw function after all event handling is processed; it was something like:

Code: Select all

while(not exit)
   event = SDL_GetEvent()
   while event.type == SDL_Key
        switch(event)
        case key_c:
              show_dialog
              update_game_choce
              redraw_browser
        case key_esc:
              close_dialog
              redraw_browser
        case key_f1
               etc...
        SDL_Flip()
  SDL_Delay()


... so I'm not surprised it's as high in the profiling as it is.

The profiling started with the game browser loaded and in a steady state, I then pressed the down arrow once which scrolls the selector down, highlights the next game (redraws the rows of bitmapped text in the browser window), populates the game info in the bottom box (list of binaries and readme files) and then (possible, if it is available) loads FOLDER.BMP from disk for the highlighted game, of which the disk IO time was not shown as a limiting factor in my tests.

I've now swapped out both the GUI / text display elements (though display of bitmaps is not yet re-implemented) to VDI calls, as well as swapping the SDL event handling to evnt_multi() AES calls. It's now quite rapid, even without an emulated blitter.

It still builds with an SDL backend if I so choose, and indeed my native Linux testing continues to work just fine that way, but on the ST it can be either an SDL linked binary (which continues to work exactly as per Linux, but with that very slow image rendering), or one which uses GEM and AES:

linux_sdl.png

Linux native build using SDL graphics and event handling (native 320x200px)

atari_vdi_aes.png

ST native build using VDI graphics calls and AES event handling routines (Hatari scaled 640x400px)

The difference in appearance is not that bad, considering the ST system font isn't precisely the same as the bitmap font being used in SDL.

Next step is loading bitmaps again, but this time using VDI. I still like the caching idea - perhaps loading FOLDER.BMP if present, doing the c2p routine and then saving back out as a native .IMG format that VDI can then load and display again the next time much more quickly.
You do not have the required permissions to view the files attached to this post.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1995
Joined: Sun Jul 31, 2011 1:11 pm

Re: Game browser with GEM/SDL xbios targets using gcc

Postby Eero Tamminen » Thu Jan 31, 2019 10:34 pm

Thanks, that's what I was suspecting. When profiling, it's better to set breakpoints around the part that you want to profile, to get profile only of what you're interested about. This way one can easier see if it code does something unwanted, and what are the exact (cycle) percentages utilized by different parts.

Quite often it's enough to select suitable function entries to indicate start and end of the activity one is interested about. In your event loop, suitable address symbols could be e.g. "_show_dialog" and "_SDL_Flip". But if there's nothing suitable, one can always just add a label to a suitable place in the code for Hatari debugger breakpoints.

PS. You can use debugger scripts to automate actions you do often:

Code: Select all

> help parse
'parse' or 'p' - get debugger commands from file
Usage:  p [filename]
   Read debugger commands from given file and do them.
   Current directory is script directory during this.
   To specify directory to be used also for breakpoint
   scripts execution, use '-f' option for 'cd' command.


(If I do profiling often, I like to automate all of it with a shell script and debugger & breakpoint scripts; including starting Hatari with the program, setting breakpoints, saving profile data and post-processing it. Sometimes breakpoints are something that gets triggered automatically, sometimes their triggering requires user activity.)


Social Media

     

Return to “C / PASCAL etc.”

Who is online

Users browsing this forum: No registered users and 1 guest