It's kind of for nostalgia that I am putting together all the sources, artwork, projects, (tools) on a disk image suitable for emulators. To me it has been fun trying to go through old hard drives and find the "almost rans" like MiniGolf (and later LiliPutz).
The shareware and commercial games (Glider, etc.) are on disk images in other repos. (You should be able to find them easily if you care to.)
When I redid Glypha (an old shareware game I wrote) last year for Steam, I decided to go with B&W pixel art for the game — even though in other ways I bent to modern hardware (a larger 16:9 screen size for example).
That B&W pixel art definitely was a defining feature of the era.
Have you considered adding a "ball dropping into the hole" animation? In the video, it looks like a new level is loaded as soon as the ball and the whole overlap to a sufficient degree. I think from a user's perspective, it would be much more satisfying to somehow see the ball go in. It would give you more of a sense of achievement before the next level is loaded.
I also noticed that the collision detection is not always perfect. Here's a screenshot from one of your videos where the ball is rolling over the side barrier: https://imgur.com/a/2tW1EOK
I'm starting to wonder whether Palm OS and other "retro" homebrew executable formats might have their actual practical uses these days, beyond the nostalgia:
I can run Palm OS .prcs, .gb homebrew ROM from itch.io etc. on my desktop, iOS, and Android, as well as on physical gaming devices; offline, efficiently, distraction-free, without any chance of in-app purchases...
Take Apotris, for example: I've bought (and probably will buy) a lot of official Tetris versions over the years, but here's an incredibly slick implementation I can play on all of my consoles, or even on any computer without installation (thanks to WASM-based GBA emulators like RetroArch Web and modern browsers having native gamepad support).
Besides that, there's just something comforting with having a single, self-contained executable that I know I can in all likelihood run one, ten, twenty years from now – which is probably not true for many iOS or even web indie games I otherwise really like.
Take all of this with a big grain of salt due to rosy retrospection, but I feel like a big appeal of Palm OS was that going online was an intentional activity (if possible at all; most of my handhelds had neither mobile data nor Wi-Fi).
As a result, it was completely distraction-free: I'd queue up news/articles (via Plucker), mail, and books for the day, HotSync in the morning/evening, and then that was it – no chance of any notification (other than pre-programmed local reminders/appointments) popping up and disrupting whatever I was doing.
Other than that, there was still more than enough to do ~forever: More Ebooks on a 64 MB MMC than I could reasonably read all summer, the top 100? 1000? Wikipedia articles, the CIA World Factbook as a PalmDoc, Space Trader... Ok, enough with the nostalgia :)
I really like the idea of getting my day's worth of emails in the morning and responding to them throughout the day while offline (using one of the great folding keyboards!). Hard to emulate that these days though. It feels artificial to put my phone in airplane mode or whatever.
I wrote code for PalmOS back around '99. One thing that stands out in my memory is the way that applications were tested. I think it was a feature of the emulator, which would fire events at your software. I forget the details, but if you could make, say, 1,000 events without crashing, it was passable, 10k was good, and 100k was excellent.
Well, I thought I was a reasonable competent C++ programmer and I was shocked at how quickly my application would crash using this tool. It was an extremely humbling experience that really opened my eyes. I often think of how effective that simple tool was at revealing bugs, but it's obviously not something that works in today's multitasking, Internet-connected devices.
The other thing I remember is CodeWarrior being the first IDE I used that had a drop-down box with all the functions in the current source file. That was a pretty big step forward in productivity.
Incidentally, I was still using a Palm Tungsten as late as 2010, when I was in Japan. There was a very simple Japanese dictionary application for Palm. Once you learn the basic rules for stroke order and direction, you could mimic any character you see using the stylus and do a dictionary search for matching Kanji. I was able to figure out a lot of navigation just by mimicking unknown Kanji that I saw on signs.
I remember the “#pragma -“ to separate the functions. We don’t have this anymore. As an alternative we have “#pragma region” to fold blocks of code but it’s different.
Wondering if I could run this on real hardware, I realized I have no idea what happened to my Palm LifeDrive when I changed to Blackberries. I miss that little chunky PDA. It was amazing for its time.
I've come across my box of Palms a few times and had limited success getting them going. Seems they don't like being in storage for almost two decades. Really loved my Palms back then.
I have both a PalmPilot Professional (with serial) and a Palm m500 (with USB), the latter is a lot easier to pocket, but the USB support is horrible in modern OS. I keep wanting to get back in to Palm dev. I even managed to get Pila to compile under macOS Catalina a few years ago.
I also have a stack of V-Tech Helio's, which is a PalmPilot clone. I don't remember why I ended up with 3 of them, but I got them to reflash the OS and never got around to it. Their whole OS source code is available online. The compiler is not easy to make to work these days though. DJGPP and I think 16bit.
On one hand I hated it, for its infuriating loading times compared to its predecessors (due to the hard drive spinning up for ~every unexpected memory access of an OS designed for having everything in RAM/ROM and literally no concept of file/block based memory at first) and its relative bulk.
On the other hand: Four! Gigabytes! That could hold more than two full movies! It was also my first Palm having Wi-Fi, which was nice.
All in all, to me it was a symbol of Palm quickly losing touch with modern developments: For example Symbian was miles ahead from an OS point of view, even though usability was nothing compared to Palm OS, and then there was the iPhone and Android, of course.
I love this and love the art design especially. Great job! The only thing I would change persoanlly is that i think it feels more natural to go in thge opposite direction with the mouse when you're aiming. Many mini golf games on Miniclip used to do it that way. Also if you're a fan of FOSS games i recommend Neverball and Neverput which is a 3d golf similator with nice graphics
Original Palm was using stylus so you don't obscure where you are aiming compared to finger touch phones and having more space in the direction of shot could be the factors.
This is beautiful! And now I'm nostalgic for my IIIxe. Through the rose colored glasses of poor remembrance, that might've been peek productivity in a handheld. It had enough functionality to remember all the things I cared to have on my person at all times, but was utterly lacking in notifications about distractions. It took me a while to quiet my iPhone so that it's not always pestering the hell out of me, but Palm was opt-in. If you didn't tell it to tell you about something, it kept its mouth shut.
I wouldn't actually go back if I could, but part of me misses that.
I feel the same. I loved my IIIxe. I'm guessing we'd be horrified at the UX now if we could go back, but at the time it was a huge boost in productivity. The handwriting language was really great. I actually wrote papers on that thing! It was great, I could work on papers while on the bus or travelling, without having to lug around a laptop. Remarkable devices.
I played with an emulator (https://cloudpilot-emu.github.io/) recently and it's honestly not that bad at all. The resolution is bad by today's standards but the basics are all there. It even has a system-wide search that looks for the input string in all your apps and lets you tap right into those records. That's pretty handy!
I like my phone too much to go back, but if I had to, I could make do.
Control over notifications is one of the most powerful UX features available. I make extensive use of geo- and time-based focus modes for the few notifications that I ever allow.
I love it! Quick suggestion: allow a moment to show the ball dropping into the hole before loading the next level. It might be frustrating denying the player that satisfaction.
Interesting project. I would say the issues had, memory leaks. debugging, etc are a lot more common in game dev than you might expect. Much of these problems have been abstracted away by game engines such as Unreal/Unity/Godot, but if you were to go into game dev with C, OpenGL, and a memory restriction (especially when hardware enforced), you might run into the same teething issues.
The level editor is a nice touch, I would be curious on the implementation as something in the same vein existed for the Tony Hawk series of games and was responsible for "Tony Hawks Pro StrCpy" https://icode4.coffee/?p=954 . Though jailbreaking and arbitrary code execution is probably a lot easier achieved via PalmOS than a minigolf side project.
You should add a short celebration before loading the next level. The "Loading" text feels very abrupt, like you did something wrong.
Display something like the text "Nice!", and try to avoid covering the hole, so that the player can see the ball disappearing into the hole.
Wait just half a second before you show the loading dialog. You can probably skip the loading dialog entirely if it is as short as it looks like in the video.
As far as I remember, the two extensions are mostly interchangeable, and are only used as a convention to indicate whether a given file contains an executable application or data.
Palm OS doesn't really have a concept of files; everything's a record-oriented database, containing either resources, including executable code, or data. Palm Desktop would just queue up every .prc or .pdb for copying during the next HotSync. (I've never tested it, but presumably renaming a .prc to .pdb and installing it would lead to it being backed up as a .prc.)
For some reason, Mobipocket (which was originally a Palm OS based ebook format) has landed on using .prc over .pdb for their books, which are definitely not executable, so every once in a while I stumble over a book with a .prc extension and it annoys me ever so slightly – it'll work, but that should be a .pdb :)
IIRC PalmOS prc and pdb are similar, in that they both contain PalmOS data, but pdb was meant to just for data and prc was meant to include executable resources too. PalmOS borrows a massive amount from 68K Mac. Codewarrior used to be the default compiler, and PalmOS uses resources in a similar way - though the actual file format is different IIRC. PalmOS apps are basically modified 68K Mac code (library?) resources. There was a tool that converted ThinkPascal generated binaries of whatever the type I don;t remember was, to prc files. SARC was what it was called.
It was called Palm Pilot - the one pictured as the very first image in Wikipedia [1]. It still works, except for some bleeding/damage on a portion of the e-Ink screen. I probably need to find the appropriate Linux based tools to load the .PRC. I wonder if this [2] still works
I have been using CloudPilot [1] to play a bunch of retro Palm games on iOS. It works reasonably well. Hopefully a native emulator will be released now allows emulators.
Ahh good memories. I wrote Pente for PalmOS back in 2004 or 2005, complete with a computer opponent using a minimax tree with alpha/beta pruning. Unfortunately I never finished or released it. It was so much fun to do early mobile development - it compared to nothing else I'd done at the time. And it wasn't easy. This is definitely an accomplishment.
It would have similar problems to WINE, without nearly as many developers who understand the bug compatibility required. One project (pumpkinos) tried but there are many apps that don’t work in it. Emulation is easier. And accurate. Source: I believe at this point I am the highest authority left on PalmOS
Unfortunately, apparently not compatible with Android 14 (there's a warning about this on the website). On my Pixel 7 Pro, it says "not compatible with your phone."
This is really cool and brings back lots of memories. I've a curious question for the game devs among you. One of the things that makes put put fun is the possibility of a hole in one. How do you make sure this is actually possible in a game like this?
Once I got a Zire 31 with PalmOS for Christmas. It became quite a fun treasure hunt to find free games and software for it. And I say treasure hunt because it was like looking for gems among piles of garbage as far as I can remember.
I am not very familiar with Palm OS, but I do like the idea of a smart device that isn’t a full on smartphone. Something like the old Palm devices or the Pocket PCs from 25 years ago. Is there such a thing today? What gets closest?
The post suggests getting a real device. Where the heck do you get a real device these days? Is there some retro hardware out there? An open source project where you send out a PCB order to Shenzhen?
ebay; the hardware has lasted surprisingly well. (That said, chrome on a recent samsung phone runs CloudPilot very responsively, start here https://archive.org/details/softwarelibrary_palm and you can just click on things and run them...)
Let me hijack this with a hate story about my wife and minigolf games.
Back in 1996 she thought maybe she needed a hobby. She was a housewife and we didn’t have any children yet. She said maybe she could do a game. At the time I was working in Microsoft C++ and the Microsoft Foundation Classes framework, building Windows apps. She had never programmed a language more challenging than Turbo Pascal.
When she asked how long it would take to even get started, I estimated about 18 months to learn C++ properly, another six months to learn Microsoft foundation classes. The six months after that to learn the windows API if she worked really hard at it. At the time I thought maybe there was a place in the Windows game market for a mini golf game.
She took less than a week to create a working, bug-free prototype, but then lost interest.
I hate people like that! Everything takes forever for me to learn.
Luckily she blessed me with a passel of pretty much bug-free and absolutely hilarious children, so I’m giving her a pass.
> She took less than a week to create a working, bug-free prototype, but then lost interest.
This is pretty common, no? Same reason why everyone thinks AI will change development: people mistake the initial time cost of building an initial prototype for being representative of the total cost of making the thing people actually demand (which mostly never happens).
Is this the difference between learning and doing? You were looking at how long it would take to learn all the foundational technologies, once that was done, she could start to code the game. Where she took the on-the-job-training approach. Work on the project, run into a problem, learn enough to solve said problem. Repeat until done.
I’m usually the learn before I start type as well, though I find it doesn’t really work for me in practice. It ends up becoming a form of procrastination.
I've just recently been trying to recover my nearly 35 year old sources and create disk images for use on an emulator. The first B&W attempt at MiniGolf is here: https://github.com/EngineersNeedArt/SoftDorothy-UnfinishedTa...
The second attempt (when I was a better programmer) was in color ... will make it on Volume 2. (I'm currently trying to put that disk image together.)