Old projects?

[kel.]

is it worth goining back to old projects, or should you just push on?

[skab]

Always worth it, if you have fun or that thing has a purpose.

I still have my Amiga game from 1988 to complete, at least into a fully playable state. Let's see when I have a chance to do that...

[kel.]

1988, christ. i don't feel so bad now, in that case i best give this a few more years to brew

I'd like to go back and at least tidy up some parts of this old shooter/shump edior i was working on, we'll see, it would realistically take up more free time than ive got, good look with your Amiga project!

[Misfit]

1988, christ. i don't feel so bad now, in that case i best give this a few more years to brew

I'd like to go back and at least tidy up some parts of this old shooter/shump edior i was working on, we'll see, it would realistically take up more free time than ive got, good look with your Amiga project!

Go for it, the world needs more shmup tools.

As someone that has little hope of coding a game I've been toying with getting SHMUP Creator. But it only makes Windows games and I really want to make something like GR++ for the iPhone.

https://store.steampowered.com/app/1289 ... P_Creator/

[tufty]

Yeah, go back. I currently have the guts of an adb wacom tablet attached to an STM32 sat on top of my oscope. project's been ongoing (well, more "offgoing") since about 2000.

[gilesgoat]

This is why ( "and to also get a bit the habit" ) I LONG ago started to document "as best as I can" in LaTEX most of my "home projects".

MANY of them been on-off for LONG time and when you pick them up after X time chances are you forgot at least 50% of what you were doing, why you were doing, what you done ...

And I am not talking about code "that you can read" but especially HW, I found out that "properly documenting whatever you do" is REALLY difficult !

But yeah "a project is always worth keep going", you may never know where it'll lead you to and/or what else you'll learn from it.

[kel.]

lol, i'll find somewhere to upload it, a large part of it is a fucking mess, cheers

[kel.]

This is why ( "and to also get a bit the habit" ) I LONG ago started to document "as best as I can" in LaTEX most of my "home projects".
MANY of them been on-off for LONG time and when you pick them up after X time chances are you forgot at least 50% of what you were doing, why you were doing, what you done ...

yeah, I get that, ive not even looked at the code for years, or even touched a line for that matter, but i remember coming back to this project after a month off it and it took about a week to get upto speed then, dread to think how long it would take to get familiar with it now.

One of the main problems with this is i was still relatively new to C++ and wasn't really taking memory management into account, and i was winging it with Qt, i never quite got my head around Qt's Model/View Programming, so i just hacked up a terrible class to handle the item list in the Group/Path Inspector. Its an effin mess. the plan at the time was just to get it to work then fix/tidy up later, lol, big mistake.

Maybe uploading it somewhere in its current state would be a bad idea right now, i still remember what i wanted to do with the editor and i think its almost feature complete but still bare bones and very crashy, I'm gonna put this aside for now, if i go back to it and manage to fix stuff, good, if not i'll try and comment/document some of the insanity before uploading it.

Its basically, just a catmull-rom spline editor, with a custom and very basic animated model that can have fire/bullet spawns attached.

[gilesgoat]

QT, the way I remember it/used it was even "before C++ was totatlly defined" I had "vague memories" about the "Meta Objects Compiler" and shit like that in some I THINK Red Hat something Linux distro.

To be fair "UIs are *ABSOLUTELY NEVER EVER EASY TO IMPLEMENT*" .. after writing "a bit of shit myself" for our own games I an inclined to think that MAYBE "a model" of "messages/events and queues" is MAYBE "the simplest way to go" as in :

"something manages the UI elements" ( buttons, menus, whatever ) .. "something happens", sends an "event" ( message ) on a queue, main loop "receives event", does something, sends a message back.

This is KINDA, KINDA "the MS approach" but it's still very messy.

I am kinda "againist" callback functions and such because it means "you have to process things as they come" I think "you need a serialization of events" but in any way I *NEVER* found "an ui lib" 100% satisfactory.

You should see the mess of my "Vector Editor" that I've done for my Z80 VecGen project it's a multi-window/menu crap ... it's a crap .. pure Windows code .. was also an attempt to "learn how to do certain things in Windows"..

But yeah "write down something" it'll help you when you'll restart the project N months ( years ? ) later.

Another - but it's not your case - FUNDAMENTAL thing I found in my HW project is "TAKE PHOTOGRAPHS AND LABEL THEM!" .. it's "almost pointless" to have "a nice schematic diagram" but then you have a board with components and you CAN NOT ( immediately ) figure out "where is R15 ?" .. "where is C21 ?" .. "was is this ? or was it that ?" .. sometime that may get the point you have to spend DAYS re-tracing back what you done just to figure this out ..

Not any more .. I take photos and I label them ...

[skab]

Always worth it, if you have fun or that thing has a purpose.

I still have my Amiga game from 1988 to complete, at least into a fully playable state. Let's see when I have a chance to do that...

Slight progress.

At the end of 2022 I dug out an Amiga 500 Plus I bought around 22 years ago and never really played with, put in a PiStorm and a Raspi 3A+, and voila, the fastest Amiga I ever had. That combo slots into the CPU socket and emulates the 68000. With the bare-bones emulator Emu68 you get about 40x the speed of an A4000/040!

And it's also the easiest Amiga to transfer files to. With the slower, Linux-based Musashi emulation engine you get a WLAN connection and a shared drive/directory between Amiga and Pi, both allowing for easy transfers to the emulated hard disk, which in my case is a partition on the Pi SD, so that Musashi and the bare-bones Emu68 can both access the same volume on the SD. Works beautifully, I can use a Workbench menu item to chose between the more flexible and communicative Musashi and the blazing fast and efficient (Pi CPU stays about 10C cooler) Emu68, so switching is just a click.

Overall a nice blast from the past. First time in about 30 years I installed a fresh Amiga OS. This was Amiga January for me, and I don't intend to stop there.

Friday I installed vbcc and vasm on my Mac, now I can cross-compile Amiga C programs and assemble Amiga 68k code. Of course I tried my 1989 game, I had already ported it from Seka to DevPak back in the days (1990), and that's basically the Motorola Asm format already. Some tweaks and I was able to build an Amiga executable from my old code and then transfer and run it on the real Amiga. I left it in a rather buggy state, with lots of things broken that once worked, can't remember if that was a problem with the migration from Seka to DevPak or if it was some other work in progress. Apparently I started some major rewrite in 1992, which I never completed from the looks of it.

But I just started, after 30 1/2 years, by fixing the most glaring bug that broke gameplay after somebody scored a goal (this is a one-on-one ball game, a bit like Ballblazer setting with a Speedball top-down look). Let's see how long it takes to bring it back into proper playable state. And then let's see if it's actually fun to play at all. It's a strictly 2 player game, so the gameplay dynamics are hard to judge without actually trying it with a human opponent. Anyway, great to see that I have now the tools at hand to get this thing finished!

[KlaxonCow]

I am kinda "againist" callback functions and such because it means "you have to process things as they come" I think "you need a serialization of events" but in any way I *NEVER* found "an ui lib" 100% satisfactory.

It's also a bit messy, because you'll already have a message queue to receive messages from the OS GUI anyway.

So having callbacks as well, just means you've got a messy inconsistency, where OS GUI messages are coming in on the message queue, but then other messages - for widgets and stuff - are directly calling callbacks instead (and, to make that generic, so anything can call anything - regardless of the class hierarchy - then Qt does have to have that whole "Meta Object Compiler", which adds extra "glue" code to your project to hook up all the "slots and signals" shit).

I agree that the easier / better approach is to just make use of that message queue. You've got to have one anyway, as that's how the OS GUI sends you messages - and you'll already have "routing" code to send messages to the right window, so just extend that to handle sending user-defined messages to your widgets and things too.

I mean, there can sometimes be a "I need this to happen right now" thing, so you can't just put a message on the queue and wait for it to be picked up the next time round the message loop. But, ah, that one tends to be the rare case, not the normal case - most messages can be processed in a leisurely way. So it shouldn't be the default, but rather if you really do need the immediacy of a callback then that's when you've got to do some extra work to make it happen. The rare case shouldn't be the default path, basically.

I do generally think that OS GUIs are designed kind of wrong. That they all just, you know, copied Xerox but I feel Xerox came in way too high level.

Windows didn't originally have games on it, because it used the high level GDI library. This was a problem, so Microsoft tried a bunch of things like WinG and then finally settled on DirectX, which they've refined. But it still leaves this "two path" thing going on - two ways to get down to the graphics, through the "high level" GDI (or GDI+ now) path or the DirectX path.

But it should really have been something DirectX-like from the off. The GUI shouldn't have attempted to do too much and be high level. It should have provided a basic underlying low-level graphics API... and the point is that Microsoft could then use that to create their GDI library on top of it. So, yeah, if you're writing a spreadsheet and don't need low-level graphics but the high-level GDI stuff, then you're still covered. Load up the GDI library and use it. But all the GDI library itself is doing is using the underlying "DirectX"-like low level calls for you.

The advantage of this is that it's only one path. Easier to maintain for Microsoft. But, more over, if you then improve the underlying "DirectX" functionality - add hardware acceleration to it, say - then your GDI library intrinsically inherits that speed boost as well.

GUIs do too much and are kind of messy and awkward for it.

This is really the essence of Wayland over on Linux. Because we had the good old Xlib, but this has tons of complicated high-level or legacy bollocks in it - bitmap fonts, etc. - that no-one actually uses, but you've got to keep and maintain, in case someone somewhere out there is still using bitmap fonts.

With Wayland, it recognised that, actually, what most modern GUI programs are actually doing is using libraries like Cairo or Pango - or maybe it's a game and it's using OpenGL / Vulkan directly to render its graphics - to draw stuff, and all they really need from the GUI is just a "here's a surface, please fill it with graphics and pass it back to me to composite it in the right place on the screen".

It's just a waste to have all this functionality in the GUI library because no-one's using it. They're using toolkits, which themselves use libraries like Cairo and Pango for drawing graphics and text (and, you know, as these projects are dedicated libraries for that exact purpose, they're generally better at it than some generic OS-supplied thing anyway).

Don't do too much. The essence of the problem is that you've got multiple applications that need to share a screen - and input devices like the mouse and keyboard - so you just need a "compositor" that arbitrates between them. Takes the application output and renders it in a window in the right place. Keeps track of mouse and keyboard focus to send the messages to the right windows and widgets. And it should do no more than that. Leave the rest to the application - because, in practice, applications and toolkit libraries and such take over such functionality anyway. Xlib providing bitmap fonts and other legacy stuff is pointless, as no-one is touching them.

Indeed, it's really "the UNIX philosophy". Do one job and do it well. And we can just stitch together different programs to do higher level things out of the "basic operations".

Don't try to do everything in one big monolithic GUI library - be this all-singing, all-dancing blob of everything. But have a "compositor" here - and all it does is handle the "sharing screen, mouse and keyboard" thing. That's all it does. Then you can have another component - the window manager - and all it does is handle the "non-client" bits and provide the general "style" of the GUI interface. Then you can put all these things together into an overall "desktop environment".

But Xerox did it the monolithic way, as they were in charge of it all - so no clear boundaries of where "compositor" starts and "window manager" ends and it's also supplying the library full of widgets too, as it's probably the same folks doing all these bits - and Microsoft followed that, for much the same reasons. But, really, GUI design is generally too monolithic and "high level" and that's what makes it so bloody messy and awkward, I feel.

It started too high-level, and you can see efforts - Wayland, DirectX, etc. - to kind of row that back and add back in the stuff that, really, should have been there as the "low level" foundation in the first place.