Rick's b.log - entry 2025/09/22

mailto: blog -at- heyrick -dot- eu

No promises

I'm basically just playing about with the SDL2 graphics library, and it turns out that it is actually pretty easy to create an HD size window (1280×720; however this one is only 680 pixels tall so nothing gets hidden behind the icon bar at the bottom) and draw a bunch of sprites into it.

The actual convoluted part is in loading the sprites, which need to be loaded as an "image" and then be converted into a "surface". Once that has been done, it's a simple matter of calling SDL_BlitSurface specifying what, where, and how.
Apparently an alternative is to translate the surface to a texture? I have no idea about the differences. I just know that how I'm doing it works.

I don't know how to make MakeFiles. No, seriously. All of my RISC OS programs are built using one MakeFile I managed to figure out while suffering from a nasty cold back in something like 1993, and it took me all day and plenty of swearing.
The important thing was that I listed all of the object files in the definitions at the top. So when I needed to use the MakeFile for a different project, I simply copied the MakeFile and edited the filenames within. ☺ I needed to use AMU to build the software, because regular Make rejected my MakeFile, and I never figured out why. But then Make was extremely finicky and pedantic about stupid crap like trailing spaces. I really wish that ROOL had open sourced the thing so I could build a version with some traps to work out why it was failing, but, like, water so far under the bridge that it's been across an ocean, turned into beer, and pissed on a wall.

#!/bin/bash if [[ ! -n $1 ]]; then echo "No parameter passed. Call with name but without .c extension." echo "Syntax: build <name>" else gcc $(pkg-config --cflags sdl2 SDL2_image) -o $1 $1.c $(pkg-config --libs sdl2 SDL2_image) fi

...and to be honest, getting that working - in particular sorting the pkg-config stuff - took longer than writing some code to splat a ghost on the screen.

You can absolutely tell that I know what I'm doing, can't you? But, hey, GHOST ON THE SCREEN.
Mission objective completed, even if you Linux wizards are thinking "JFC, that's the most convoluted nonsense I've ever read".

Now, I want to make one thing very clear. The game code is heavily tied to RISC OS. For example, the code that shows the startup logo is this function.

void menu_titlescreen(void) { // Show the fancy title ;-) char verinfo[40] = ""; // buffer for constructing version information message // Cue up the theme MP3 at this point mp3_playtrack("<Mamie$Dir>.samples.theme"); // Switch to draw into bank three screen_selectdrawbank(2); // Render the JPEG into bank three __asm { MOV R0, (int)&title__base // address MOV R1, 0 // X MOV R2, 0 // Y MOV R3, 0 // Scaling MOV R4, (int)&title__limit - (int)&title__base // Length of data MOV R5, 3 // plotting flags (dither using error diffusion) SWI (SWI_JPEG_PlotScaled + XOS_Bit), {R0-R5}, {}, {R0-R5, PSR} } // Overlay some information on the program font_draw(textfont, 870, 80, appcopy); font_draw(textfont, 870, 60, appsite); snprintf(verinfo, 39, "Version %s %s", appvers, appdate); font_draw(textfont, 870, 30, verinfo); #ifdef DEVBUILD // If this is a dev build, mark that too snprintf(verinfo, 39, "Dev build: %s, %s", buildtime, builddate); font_draw(textfont, 200, 8, verinfo); #endif #ifdef DEMOBUILD font_draw(menufont, 150, 8, "DEMONSTRATION VERSION"); #endif // Make it happen screen_whizz_from_second_buffer(); return; }

That's not to say it's impossible. It isn't. If RISC OS can do it, then Linux can do it with bells on top. But it would mean going through every bit of the code and adding platform specific conditionals, whilst accepting that some things might need to be thrown away such as the fancy whizz-in screen effects that, well, let's say it directly screws around in screen memory because the layout of that is a known known.

I think the biggest impediment, however, is going to be actually figuring out how to translate stuff to Linux. For example, I don't think I can do anything with screen buffers as this is handled by SDL itself. I just splat stuff onto the screen and, okay, it stutters from time to time but there's no tearing or anything like that. I think it composites into a bitmap and then renders the bitmap? The stuttering might be because there's currently no speed limiting, it's just running in a loop as fast as it goes.

rick@Rick-E200HA:~$ cd ~/Coding/mamie rick@Rick-E200HA:~/Coding/mamie$ ./drawtest Starting initial draw test (IA64/Linux/SDL). Compiled at 18:50:30 on Sep 20 2025. SDL initialised. Loaded asset: sprite brick->111 (left wall with floor) Loaded asset: sprite brick->112 (floor) Loaded asset: sprite brick->113 (floor with right wall) Loaded asset: sprite ghost_00 (normal ghost frame 0) Beginning animation loop - press a key to quit. Received SDL event type 4352 (&1100)- SDL_AUDIODEVICEADDED. Received SDL event type 4352 (&1100)- SDL_AUDIODEVICEADDED. Received SDL event type 4352 (&1100)- SDL_AUDIODEVICEADDED. Received SDL event type 512 (&200)- SDL_WINDOWEVENT (event 1). Received SDL event type 512 (&200)- SDL_WINDOWEVENT (event 2). Received SDL event type 512 (&200)- SDL_WINDOWEVENT (event 1). Received SDL event type 512 (&200)- SDL_WINDOWEVENT (event 4). Received SDL event type 512 (&200)- SDL_WINDOWEVENT (event 3). Received SDL event type 512 (&200)- SDL_WINDOWEVENT (event 12). Received SDL event type 512 (&200)- SDL_WINDOWEVENT (event 15). Received SDL event type 768 (&300)- SDL_KEYDOWN. Received SDL event type 771 (&303)- SDL_TEXTINPUT. Received SDL event type 769 (&301)- SDL_KEYUP. Fell out of loop, we're done. Bye-bye! rick@Rick-E200HA:~/Coding/mamie$

I had to go rummaging around in header files like this one in order to translate the event types to names. But what are all of the window events? I think that is over here.
So, yeah, it's a bit of a slog.

Oh, and to add to that I have no clue about C++, which does rather complicate the various things I've found online. I need to downgrade them to straight C, and not always correctly. ☺ So, fix what I messed up, and then we can keep on going...

Anyway, this is a real back burner project. My target was to draw some scenery and (roughly) animate the ghosts on top of it. I have now done this. Whether it ever goes further or not, I don't know and don't want to say. Like the title says, no promises.

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺
As of February 2025, commenting is no longer available to UK residents, following the implementation of the vague and overly broad Online Safety Act. You must tick the box below to verify that you are not a UK resident, and you expressly agree if you are in fact a UK resident that you will indemnify me (Richard Murray), as well as the person maintaining my site (Rob O'Donnell), the hosting providers, and so on. It's a shitty law, complain to your MP.
It's not that I don't want to hear from my British friends, it's because your country makes stupid laws.

You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

« September 2025 »

Mon

Tue

Wed

Thu

Fri

Sat

Sun