Steeph's Web Site

Menu

Entries tagged 'cat:Software'

SBWG 0.11.1

I'm glad to have this version done and published. Even though it has new features compared to the last published version, I've used it enough to feel relatively comfortable saying it is also more stable and has fewer bugs than the last version. There are known bugs still left. But those aren't new.

Caching options and settings are slowly getting a bit elaborate, but also close to what I imagined them being able to do. There are new cachegroups and parts of entries can now be chosed as individual cachegroups, giving the user more control over what is cached and what caches are used. The lifetime of caches can now be set to make sure that no matter how the caching options are used, no outdated content, tags, attachments, etc. will stay on the web site for too long because cache files have been forgotten to be purges. The cache lifetime can be chosen from 1 second to unfinite. The directory used for persistant caches can now be chosen via command line option. I think the caching options are now in a state in which they can seriously be used reliably. Changes to existing cachegroups, like in previous versions, will probably not be made anymore. Just more cachegroups will be added.

The README file has grown a lot. Not only from new features and options. It's now also more complete. A lot of bugs have been fixed. And some general little code quality improvements took place. The stylesheets of the example web site have been improved a bit.

The messaging and logging system has been completely rewritten. It's not really an important part of the script and strictly doesn't matter for its functionality at all. But I decided to have a messaging system and a logging option that doesn't rely on shell redirects. So I did want to redo it properly. Different message types can now be redirected using file descriptors. The option parser has also been party re-written. It's approaching a state in which it's close to what I think personally a complete option parser for Bash should be like.

Alternate styles can now be defined in a web site's settings file. That way alternate style sheets will be offered to the web browser. If the browser supports alternate style sheets, the visitor can select from them to view the page in a different style. There is now an option to change the tagstyle, enabling a web site to have tags of the same type grouped for a more readable look of the entries' headers. Tags now show in parenthesis the number of entries that carry that tag. The number of file attachments is also displayed below entries.

The options for generating a single entry, page or gallery that is not located in the input directory/isn't actually part of the web site can now be used. They were very buggy or nonexistant before. Entries (and other items) with duplicate names are handled in defined ways now. Text files can now be used as file attachments to entries. But if the script determines one to look like a SBWG source file, it is omitted/not displayed/not linked to.

There are still big plans for future versions. Small and big features as well as a complete re-thinking of how the input directory is structured. Nicer looking web sites, more flexible command line options, more options for speeding up the script in cases where a complete website is updated/re-built. A pause like the one before this release will probably occur more often in the future.

I remember when Firefox got the new feature to re-open the last closed tab. That was a real useful invention. Do you know what we did before that was possible? … Yes, it was exactly how you imagine it.

I also remember when web browsers didn't have tabs. I'm still not sure whether that was such a good invention after all. Why is there no popular alternative? Opera folded a long time ago with its thumbnail buttons. There are extensions to order, manage and group tabs differently. I think I'd like to try vertical tabs in a bar again for a while. Or just separate windows. Let the window manager manage them. There must be a good reason why every attempt to do that is quickly abandoned. But I'd still like to try it. There are browsers that don't have tabs. But those don't have an engine that I'd like to use for daily web browsing.

It doesn't look like there's any interesting setting to change the tab display in Fitefox.

Bash Tip

In a script, if you open a file descriptor like this: eval exec 3>&1 and redirect output from certain commands to it like this: echo blub >&3 then you can redirect only that certain output to a different file if needed when calling the script. By default all goes to stdout, but when called like this: ./script 3>>file1 >>file2 then you can check the separated output in file1 and the rest of stdout in file2.

SBWG 0.10.11

It's been two months since I published a new version of SBWG (and therefore since I worked enough on it to make me feel that an increase in the version number may be justified). I hardly get around to working on it, lately. But when I do, I try to make some solid small steps towards the improvements I wish do be done to SBWG.

So, now there is a new version (0.10.11) but I haven't published it yet because before I do I want to test it a bit more when I'm not as fucking tired as I am right now. Writing this entry could actually be considered part of the testing that I still want to do. But as I said, I'm fucking tired right now. So I'll continue this entry another time.

Edit 2022-09-12: I did some tests with fake content offline and feel confident that I fixed more than I broke in this version. I'll add it to the project page soon.

Two long procrastinate areas that have been overdue to get fixed for a while now are permanent caching and parallelisation. For permanent caching, the bugs that I found are fixed. Aggressive caching with option `--cache` (`-C`) works and certain groups can be selected (excluding others) for permanent caching. In my test this speeds up everyday web site re-generations by up to 100%. But it also means the user has to be aware of the cache files that persist after SBWG is done and will be used the next time. Changes to existing entries will not take effect without removing the relevant cache files. For parallelisation, the bugs that I found and that affect the generated HTML are fixed. I still consider parallel mode to be experimental. Sometimes messages on stdout are weird or cut off. But who uses very verbose mode and looks at every message anyway? Parallelisation is functional and usable is what I mean to say. In my test on a Core i5 with 4 cores (8 threads) it speeds up everyday web site re-generation by around 380% with default settings. It depends a lot on how much of web site generation is generating thumbnails and other image sizes of file attachments or gallery images. Those aren't sped up that much because the CPU already is the bottleneck for those. HTML file generation profits more from having more parallel threads than CPU cores (or threads) running.

Klik & Play

I have been wanting to write about this piece of 16 bit Windows software for a quite a while. I don't know why.

I'll just start this entry and continue whenever. Just want to have it started for now…

When I got my first own computer - that must have been around 1996 or 1998 (probably closer to 1998) - I got most of the software that I used for free from magazines that came with diskettes or CDs. Because it was cheap. I reckon the publishers didn't really pay for the software that was on them, or may even have gotten payed for including restricted freeware/shareware on them. Because most of these magazines weren't even pricey for the magazine themselves, and you got the software for free. One of these disks included a demo of "Klik & Play" (That's how it's spelled everywhere. I'm pretty sure it was spelled "Klik 'n' Play" in the logo/intro animation, though. But whatever.) A programme that promised to enable the user to create computer games without previous knowledge, without writing any code, without knowing how to programme at all. I checked it out just because it was there. I remember thinking "who are they trying to fool with that language and why?" because of the slogan and promises (that I don't remember word by word). But after playing with it for a while, I was positively surprised by how true the claims seemed to be. You could really create a video game without knowing how to code.

I thought this piece of software genius back in the day. I was - idk - 12 and hadn't really thought of writing my own software. Computer software, in the minds of the people that I had to do, wasn't something that you wrote or edited yourself. Creating your own programme, writing your own code wasn't really in the realm of possible things to do with a computer. Almost as much as it is viewed now. I mean, editing a .BAT file in DOS was the hackiest one would get among my friends, and even that was rare. So the fact that the developers (Europress Software - Wikipedia credits Francois Lionet and Yves Lamoureux) managed to allow me, to create a simple, 2D, actually playable game, and the way they managed to allow this by using mostly to only the mouse, impressed me.

I think I don't want to explain how creating a game with Klik & Play works in detail. You can search the web or watch a video for that. But to get an idea of what it was like, and of how simple it was: On any given screen ("level") you can click an icon to add an object. You can select from a number of categories or add your own graphics and GIF animations. Then you could choose whether that object is just a background object (not doing anything, not moving, not interacting with other objects, not changing, ...) or if it represents one of the players. If it's a player, you can choose a set of controls. Most of the actual programming takes place in a table. On one axis are all the objects, on another axis something that can happen to or with them. And in the fields of the table, you choose what's supposed to happen when this circumstance ever comes true. So the table sort of represents a huge set of possible interrupts. Common things that can be acted upon are: An object touches an edge of the screen, an object touches another object, a key has been pressed and released, ... And examples for possible actions are: Move an object by incrementing/decreasing coordinates or by setting them to a fixed value, changing an objects velocity, jumping to the next or a specific screen ("level") in the game, increasing the player's points by 1. Just with there few examples, you could: Make the player object jump when you hit the space bar (e.g. in a jump&run style game), make it stand on the ground object and platforms (e.g. in a platform style game), make it move left and right when you hit the arrow keys, make it reappear on the other side of the screen when it leaves of side (like in Asteroids), make it collect and count coins, make it die when it touches a deadly enimy and only one life was left on the counter, go to the next level when this one is won, ... and much more.

Note that this is all done by only clicking on objects, buttons, lists, menus. Once you got used to the interface and know what's available, it's really easy to use. There is a feature that makes getting started with a new game even easier though. You can run the game in a mode where every event for which an action can be defined, interrupts the game and lets you choose an action (or choose that for this event it shouldn't ask/interrupt again) and then continue the game. The ball touched a stone, what do you want to happen? Bounce the ball, delete the stone object, increase variable A by 1, play CLICK.WAV. The ball touched the left edge of the screen. What do you want to happen? Bounce the ball, play CLACK.WAV. …

I think I could have handled writing code myself at that age, at least after having created some silly game-like things in Klik & Play. But nobody showed me and teaching myself seemed overwhelming. (It wasn't really. Good books and reference guides existed back then. But I didn't know.) Anyway.

You could play the game file by opening it with Klik & Play or you could compile it, which produced two files: an 16 bit EXE and a game file. I think the latter contained all the graphics and sounds and the executable was the actual game. But I'm not sure.

There were a number of programmes around in the 90s that promised to let you programme and/or create your own games without knowing anything about computers first (or that made some similar claims of that sort.) I tried two others, that took a completely different approaches. But I think they deserve their own entries. I could probably plan to make a series about these sort of tools where I start with the goal to create a complete list of functional, worth mentioning programmes, and end up with a pile of unexpected feelings of resignation over the fact that there are too many products to mention, like I did with alternative operating systems.

(tbd: proofreading, add links, add screenshots, fix misremembered details, write continuation about Klik & Play games.)