Lazarus
Programming => Graphics and Multimedia => Games => Topic started by: Bad Sector on May 13, 2020, 06:59:46 am
-
You might find this interesting: there was a game jam recently for making an MS-DOS game, so i decided to try and make one in Free Pascal. The jam was for two months (originally one, but extended due to Covid stuff - which was perfectly fine for me as i could take my time to do things) so there was plenty of time to do something interesting.
I decided to make a simple 3D game and after a while i made a simple 3D platformer/adventure hybrid (really more of an adventure game and less of a platformer, though initially i had more platforming in mind), kinda reminiscent of early Tomb Raider games but in a sci-fi setting.
I'd attach some screenshots but i can't see a way to do that, but you can find everything here:
https://bad-sector.itch.io/post-apocalyptic-petra
The game comes with an editor and the source code under zlib license. The game itself only needs Free Pascal to compile and the editor needs Lazarus. I think both are also decently commented so you could use them as a base for another game (the game specific bits are in their own directory so it shouldn't be hard to rip them out). However since both of them (as well as an animation tool that i haven't uploaded anywhere yet because it isn't very usable - i'll try to fix its issues and upload it at some point later) were made in the span of two months - actually more like ~5-6 weeks since i was busy playing the Dishonored series after they got released on GOG :-P - they are a bit hacky at points. And there are some bugs of course. Also they're far from optimized (the game looks like TR1 but needs at least a Pentium 3 for smooth gameplay - though if you have one with a real CRT, it will be very smooth as the game's refresh rate is the same as the VGA refresh rate which makes motion feel butter smooth on a CRT VGA monitor).
If you want to see some snapshot's of the game's development check my YouTube videos: https://www.youtube.com/user/badsectoracula/videos
Search for "DOS software render test" - that was the first video when i started writing the game and go upwards, i was uploading progress videos every few days (there are some big gaps - that was when i was playing Dishonored :-P).
EDIT: attached screenshots
-
I'd attach some screenshots but i can't see a way to do that, [...]
Click on "Attachments and other options" to access that funcionality in the post editor (see attached image ;) )
-
Click on "Attachments and other options" to access that funcionality in the post editor (see attached image ;) )
Thanks, i expected some sort of insert image button in the editor toolbar :-P
-
Great, another game to the bag. ;)
I'm not a Tomb Raider fan but I'll give it a try.
-
Well, even though it looks like Tomb Raider, it plays more like an adventure game than a 3D platformer. There is some platforming in there but it is mostly easy stuff. Most of the time you'd be exploring the rooms and solving simple code puzzles.
-
Hi,
Just tested on Linux, it was complaining about not find SDL unit. I've added Engine/SDL in the search path and that solved the problem. Of course I needed to install libsdl development files.
Another thing, the GSound variable is not initialized on Linux, so it crashes whenever it accesses it. Maybe adding a fake sound driver in this case? I've added some "If Assigned(GSound)" and that seems to work.
Now the game runs, but the colors are buggy. The palette of the textures seem a bit undefined. See attachment. Also the window is very small. Maybe it can be turned to fullscreen?
-
The SDL code was written about two months ago as a quick and dirty port to Linux so i could use a profiler under an emulated Pentium MMX running Slackware (https://i.imgur.com/4X7lvZ7.png) (though it didn't end up helping much since perf requires functionality that is only available on Pentium Pro, which isn't emulated by 86box). That was before i had written any code for sound, so it makes sense it doesn't work (and perhaps there are a couple of other things that do not work).
About the colors, the palette is actually fine (notice the 3D models) but for some reason it looks like the wall textures are not loaded and replaced with an "error" texture (it looks like garbage because i used another palette when i originally made it and didn't convert the texture to the new one). Check if you have a Data/Walls directory with files names 1.raw, 2.raw, etc.
I'll make a proper port at some point and most likely will use X11 and ALSA directly instead of SDL since SDL has some issues i dislike and also perform scaling like the Win32 version. This one was a quick port though for development reasons so SDL was fine for that purpose.
-
No problem.
I have the Walls directory inside Data.
-
Hm weird, it should work then. Perhaps some case issues? It should be 'Data/Walls/1.raw' (notice the capitalized D and W).
-
Nope case seems fine.
-
I see. Weird. I'll check it at some point later when i make a Linux version, it should be something trivial.
-
So i added proper Linux support (fixed SDL backend, added audio and mouse input, etc).
The issue with the wall textures was that i was lowercasing the filename during resource loading to avoid duplicates in the resource cache but the directory contained an upper 'Walls'. I fixed this by lowercasing the stored name only instead of also trying to load the file with the lowercase name.
Note that you do need to have SDL 1.2 installed for the game to work (the library should come with pretty much every distribution out there - under Debian derivatives it should be the libsdl1.2debian package).
-
Hi!
Thanks, that's much better. The 3D, textures and sound works well.
Mouse input doesn't seem to work (though I am on VirtualBox, that might affect things).
The window is set to the size of the screen, though it is under the taskbar, so the bottom of the screen is hidden. So the first time I could not see the Quit option when pressing Escape. So I reset the machine to exit the game... Maybe add some shortcuts like Alt-X or Ctrl-Q?
I have no idea what to do after the first door is opened. I found a button that doesn't work and a room with electrical floor where Petra dies.
-
Under VirtualBox you need to disable mouse integration because it messes up with relative coordinate reporting. It is just how VirtualBox works.
You can adjust the window size and internal rendering (for the software rendering version) using the -w<width> -h<height> and -x<width> -y<height> parameters respectively. Check the linux.txt file in the linux archive. By default it uses 960x720 which is ok for windowed mode but for fullscreen might not be that ok. I'll probably change the default to 640x480.
You can toggle the mouse grab to close or move the window with the Pause key (also mentioned in the linux.txt file).
About the button, notice what Petra says: "I need to find a cover" - so explore the rooms to find a cover :-). Check hidden corners, etc.
-
Made a port of the game to GCW Zero, an old-ish (from 2013) open source MIPS-based gaming handheld running OpenDingux, a Linux distribution for open source MIPS-based gaming handhelds :-P (yes, it turns out there are a few of them, mainly made by Chinese companies and advertised as "retro gaming emulators" though GCW Zero was made in USA).
Here is a photo: https://i.imgur.com/coFBWXx.jpg
Porting the game wasn't that easy, mainly because the handheld is running in a busybox+uClibc-based environment. Well, uClibc is what made things harder, not busybox. I ended up creating a 32bit Slackware VM (the official SDK binaries were only released for i386 Linux), downloading i386 Free Pascal 3.2.0 and building a MIPS cross-compiler and then smashing everything together under /usr :-P.
It still wasn't completely enough because even though GCW Zero has SDL in it, Free Pascal's SDL bindings bring in X11 even though that wasn't used, so i had to modify sdl.pas to remove any reference to X11 and pthreads - which in turn tried to bring in the C library, which caused some linking issues due to missing symbols. I guess i could try to fix that but, eh, it was easier to just get rid of the dependencies :-P.
Also it took me way too long to figure out i need to explicitly set the dynamic loader to /lib/ld-uClibc.so.0 (or whatever) instead of the default (/lib/ld.so.1 doesn't exist in GCW Zero).
But anyway, now it is ported and it should work on GCW Zero and any compatible handheld. I do not have any myself though, but from what i've heard most OpenDingux handhelds should be compatible.
-
Cool :)
-
Interesting game. But I have question about DOS version. Why haven't you tried to implement page flipping instead of copying? It's tricky thing, but it could improve performance.
Biggest problem - it really looks like knowledge about making games back then was some kind of secret. Because you can't find any information about that even in very detailed sources, like this one (http://www.osdever.net/FreeVGA/vga/vga.htm). So, yeah, we have many references, but zero programming guides. And all this references lack really important bit of information - VGA doesn't support mid-frame page flipping, like modern video cards do without vsync. I.e. vsync is actually required. And vsync is also very tricky thing, because some sources say, that you can't rely on IRQ2, and doing "wait for vsync" operation wastes too much time. It's really hard to find workaround for all that limitations. That's what making old games was about. It was real science.
-
Assuming page flipping is faster, it wont really make much of a difference - if any - since the performance bottleneck is on the rasterizer, followed by the renderer, followed by the sound mixer, etc. I also use copying on Windows with DirectDraw and when profiling the game on a Pentium 166 the copying part doesn't even register at the profile.
But also page flipping assumes unchained mode which in turn means non-linear memory layout. This would complicate the rasterizer significantly to the point where you'd be actually losing performance instead of gaining it.
Another thing to consider is bus speed: accessing the VGA memory is slower than accessing system memory. The game has both overdraw (meaning the same pixels -and thus memory regions- will be touched multiple times) and reads back from the framebuffer (for translucency effects). Doing everything in system memory and then copying the final frame to the VGA memory means that the VGA memory being slower wouldn't affect much.
Of course another (or really, the main) reason is that i wrote the simplest code to get stuff on screen since i had a ton more things to do :-P. But i did consider it later when optimizing the game, though it never ended up being a bottleneck and thinking about it made sense when considering how the memory is accessed.
FWIW DOS Quake also uses the copying method for VGA.
It could be usable for linear memory VESA modes on graphics cards with fast memory access but those are a can of worms i'd rather not bother with.
-
I always forget about that VRAM wait state. But anyway, copying 64K of data shouldn't be irrelevant. Of course it depends on optimization of other parts. I remember, that back in old times, when I was trying to make my own game for i286 12Mhz, copying video page was taking all free CPU cycles, not leaving anything for game logic.
Yeah, unchained mode is little bit harder, but it's about writing every 4th pixel and then repeating it for other 3 bit-planes.