Official MICRO-blog THREAD for "Finish Your Damn Game Engine"

Make games! Discuss those games here.

Moderators: Bob the Hamster, marionline, SDHawk

TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Official MICRO-blog THREAD for "Finish Your Damn Game E

Post by TMC »

(Boring introduction)

I didn't want to intrude in Harlock's Finish Your Damn Game contest thread with posts not part of
his contest (although I should be there, later!), but I do want to join in the spirit of open
development and providing some activity by talking about work I'm doing on the OHRRPGCE itself.
Anyone else programming engines and so forth is welcome to join in ;)

About a decade ago, Mike used to have a blog at ohrdev.com about OHR development, with occasional
posts by James or Simon. The OHR mailinglist receives the changelog messages for all changes (SVN
commits) to the OHR source, but 95+% of the commits are very boring work on code cleanup, the build
system, porting, documentation, tests, bugfixes that affect almost nobody, etc. A thread here on SS
seems like a good way to show off the actual interesting stuff that happens.

The title of this thread is intended to remind me to work on important stuff. The OHRRPGCE
will never be "finished", but I'd like to start making real progress towards that unattainable goal!
James, Simon and Mike all seemed to be far more results-orientated than me, while I was the person
working on the OHR originally largely because I liked disentangling difficult QuickBasic code. We've
spent a huge amount of time cleaning up the OHR's source code over the last nearly 12 years. The
justification is that it makes features and bugfixes easier. And yet there are still many important
things that haven't been implemented. I'm very prone to working on unimportant stuff, like obscure
features hardly anyone wants, instead of the super important but hard stuff like animations. I'll
avoid posting dry details here; if it's not interesting enough to post I might have to admit I'm not
using my time efficiently!
Last edited by TMC on Mon Feb 20, 2017 3:42 am, edited 4 times in total.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

What better way to start a view into the excitement of engine development than with more code cleanup?
(Unfinished work like the 'run game' command shall wait.)

(I meant to post this soon after the intro post, but predictably got badly distracted by even more code cleanup and bugfixing when I went to take screenshots!)

A couple of weeks ago MirceaKitsune contributed two patches to add per-textbox (each-)line sound-effect and Silence textbox music options. It's really nice to receive patches since James and I have been working alone for a while. He complained about the difficulty of adding those options due to the ugliness of the menu code, and I noticed the menu options were confusing and out of order, so I went and improved both (as usual, it was more work than expected).

Before:
Image

After:
Image

For the past years James and I have been updating both Game and Custom to run at resolutions higher than 320x200. You can see that here. (You can only resize Custom's window if using gfx_sdl. gfx_directx is the default on Windows, and doesn't support it yet. I plan to implement it soon).
There are so many menus that after years the majority still behaved badly in Callipygous at higher resolutions, but James did a big chunk earlier this year. After updating the textbox editor I felt like doing some more, and spent some days on that. Now there are only a few left!
The map doorlink editor was a particular nuisance, a lot of work went into map editor cleanup there. As a side effect, I could remove the limit on NPC definitions (not instances), which used to be 500 (which I'm sure nobody would ever hit).

I expect that Custom will be fully updated and default to running at larger than 320x200 in the next version.

Before:
Image

After:
Image


Finally, to more important stuff.
Back in 2007 Mike built on Simon's Windows port work (which rewrote all the low-level code) and started converting the whole engine to 8-bit sprites, replacing the 4-bit sprites which had been used since the DOS days to conserve precious memory (all graphics had to fit into 128KB of RAM!) Everyone joined in and everything was rapidly switched over... except for the sprite editor. It was a terrible mess. Because the editor and file formats were stuck in 4-bit, all that work had no visible effect at all.

So I spent the last days of the year doing a lot of work in the sprite editor (thankfully James had already done heaps of cleanup in 2008 and 2009, so that code wasn't that bad), and now the sprite editor internally uses 8-bit sprites, something I've waited most of a decade for. There are just a few things left to do (new file formats and palette editor user interface) before allowing more than 16 colors per sprite.
Oh, and I also introduced (and then discovered and fixed) 5 bugs (including two crash bugs) during this cleanup, so that warning in IMPORTANT-nightly.txt is serious.

As a bonus, thanks to the cleanup I added a Redo button and increased the undo history size from <32KB to 16MB.

Next, I'm going to rewrite the spriteset editor and create an animation editor.


Note: it turns out that Windows and Mac nightly builds haven't been rebuilt in two weeks, due to a server config problem. (Keeping nightly builds working sucks up a surprising amount of our time!)
Last edited by TMC on Mon Jan 02, 2017 6:20 am, edited 2 times in total.
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

This is an exciting thread! I love reading all this stuff, and it makes me feel motivated.

I wish I had more free time for OHRRPGCE work right now. I would really love to finish the slicification of the built-in menus, and to finish the planned conversion of item data to reload format
User avatar
marionline
Metal Slime
Posts: 673
Joined: Sat Feb 26, 2011 9:23 pm

Post by marionline »

That's a cool thread idea! :o
Thanks for writing.
Anyone else programming engines and so forth is welcome to join in ;)
That would be cool! I'd like learn about how to design/structure a game engine, so I'd be reading this! If I remember correctly, there was a text on 'how not to do this' in the wiki that mentioned the ohr source code.

About working on the OHR source code: Will there also be lines from the source code shown and maybe even explained? Or is that to much work to ask for?
So I spent the last days of the year doing a lot of work in the sprite editor (thankfully James had already done heaps of cleanup in 2008 and 2009, so that code wasn't that bad), and now the sprite editor internally uses 8-bit sprites, something I've waited most of a decade for. There are just a few things left to do (new file formats and palette editor user interface) before allowing more than 16 colors per sprite.
Wow! Sprite will have more colors!
That is really great news! :D
User avatar
Pepsi Ranger
Liquid Metal Slime
Posts: 1457
Joined: Thu Nov 22, 2007 6:25 am
Location: South Florida

Post by Pepsi Ranger »

I guess this means we can pester you to finish needed features here instead of everywhere else? Cool!

I like this thread. I do read the devlogs that show up in my mailbox, so I already know a lot about what's going on, but seeing a nice write-up with screenshots is way better. Plus, it's nice to see what your intentions are with the changes you do make instead of merely speculating and asking you about them months later whenever I think about it.

I'm really looking forward to native support for higher resolutions, where sizes other than 320x200 or 640x400 can be set to full screen without trouble (I'm looking at you, 480x300). One of the things I've discovered in the last few years that's steadily driven me crazy is that custom menus and slices can really eat up a lot of screen space, which makes window overlays and tooltips and things really cumbersome to use, as they greatly obstruct the view of the map itself, and sometimes that's undesired. Changing native resolution and allowing full screen support of the new resolution is a step in the right direction. Looks like we're almost there. Awesome.

Hopefully this thread will do its job and keep you motivated to work on important things. Sounds like you're preparing to tackle some majorly overdue major stuff. Can't wait to see what's next.
Place Obligatory Signature Here
User avatar
Taco Bot
Meat, Cheese, and Silicon
Posts: 484
Joined: Fri Jul 18, 2014 12:15 am
Location: Santa Cruz
Contact:

Post by Taco Bot »

This thread is making me giddy with excitement! The resolution problems were something that had been bugging me for a while, so it's so cool to see that's fixed. (For example: I edit maps in fullscreen, then go to edit sprites, and my res gets forced back down to 640x480 :/ )

Can't wait to see what progress you guys make on this!

Also, BASIC is the first language I ever learned. I might have to brush the dust off of my freebasic compiler and help out with the engine. :)
Sent from my iPhone
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

I could easily post snippets of source code as well; I didn't think anyone would be interested. My intention wasn't to provide an introduction to working on the OHR. There is a category on the wiki with a few useful articles, though.
marionline wrote:That would be cool! I'd like learn about how to design/structure a game engine, so I'd be reading this! If I remember correctly, there was a text on 'how not to do this' in the wiki that mentioned the ohr source code.
Those warnings were about the bad quality of the OHR source code, which is better than 10 years ago but still not great. I definitely notice that I have learnt much less from it compared to reading good quality code. But there are other problems too. It's big*, complex, and disorganised. If you are just writing a single game rather than a game editor then you can do many things in simpler ways. And you can use lots of libraries and a high-level language to make things easier; FreeBasic is low-level and we have a bad tendency to write things from scratch.

On the other hand, since you are using the OHR, being able to extend it is very helpful!

* The OHR source is about 130k lines of code, which for comparison is about a quarter of Godot, a large engine quite similar to Unreal Engine, with 2D, 3D, networking, ports to many platforms, its own scripting language, visual scripting system, shader language, code editor, etc, and over 300 contributors.
(For example: I edit maps in fullscreen, then go to edit sprites, and my res gets forced back down to 640x480 :/ )
I didn't mention it, but that's something I fixed while working on the sprite editor (the undo history was previously stored on half a spare video page, which interfered with changing window size. Of course, I could have just locked the size of that particular video page...). But the tileset editor is still locked to 320x200.

...make that was locked. I've just removed the window size limitation from the tileset editor, by locking the sizes of the spare video pages. There were just a few small hiccups that needed fixing.
I'm really looking forward to native support for higher resolutions, where sizes other than 320x200 or 640x400 can be set to full screen without trouble (I'm looking at you, 480x300).
You mean that the screen should properly padded and scaled so that it appears correctly in fullscreen? gfx_sdl tries to change the monitor resolution, which is rather annoying. I think gfx_directx actually handles it better, since it leaves the monitor resolution alone and pads and scales the image. There were a couple bugs in the fullscreen mouse handling which I fixed or was in the process of fixing.
Last edited by TMC on Tue Jan 03, 2017 3:14 am, edited 2 times in total.
User avatar
Pepsi Ranger
Liquid Metal Slime
Posts: 1457
Joined: Thu Nov 22, 2007 6:25 am
Location: South Florida

Post by Pepsi Ranger »

TMC wrote:You mean that the screen should properly padded and scaled so that it appears correctly in fullscreen? gfx_sdl tries to change the monitor resolution, which is rather annoying. I think gfx_directx actually handles it better, since it leaves the monitor resolution alone and pads and scales the image. There were a couple bugs in the fullscreen mouse handling which I fixed or was in the process of fixing.
My experience with custom resolutions (like 480x300) is that they can be set just fine as a window, which is rather small on today's monitors, but their full screen selections via the actual window doesn't work. You have to set them from within the game, which is fine, but maybe not ideal as an only means for resizing. But, I just downloaded the most recent SDL-SDL backend (from December 17), and it looks like it actually does a lot of what I want already, so maybe we're closer than I thought when I wrote earlier. I'm still struggling with the idea that screen size can affect how full screen adjusts to fit the monitor. That particular backend seems to stretch the screen to fit if set to a specific screen proportion.

But never mind. It's almost 5am, and I've been experimenting with resolutions set at different pixel and screen proportions, and it's making me delirious. I had set out to make a point, and then I tested the engine prior to finishing my response, and discovered that I was about to be wrong about most of it.

That said, I think what's coolest about resolution adjustment is that setting the screen size to below 50% can potentially add anti-aliasing to the game, which in turn makes your game look like it's being broadcast on an old television when set to full screen. For anything made to look 8-bit, this can be an advantage.

Anyway, setting the resolution does remind me that we need the ability to set not only the vertical position and size for textboxes, but also the horizontal settings. Make the resolution high enough and the text will look tiny in comparison. The ability to change resolutions makes the need to adjust textboxes in more ways than currently available a necessity.

I hope I'm making sense. I'm very tired right now.
Place Obligatory Signature Here
User avatar
Ichiro
Slime Knight
Posts: 238
Joined: Sat Sep 11, 2010 1:20 am
Location: john madden

Post by Ichiro »

I have a DLL for working with OHRRPGE files on hold. So while I can't work on the engine itself per se, I can certainly work on utilities.

If you guys want, I can give you a link to my GitLab.
Image
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Are you talking about HamsterTools? Have you moved off GitHub? The (increasingly misnamed) OHRRPGCE Source Ports page only links to the Github page.

Of course, new file formats means that utilities need to be updated or stop working, and the graphics formats are under the gun now. Backdrops file format will probably change soon, tilesets not very soon. Does anyone still use ohrgfx? I remember that was very popular years ago, before we had full spriteset import/export.
Pepsi Ranger wrote:That said, I think what's coolest about resolution adjustment is that setting the screen size to below 50% can potentially add anti-aliasing to the game
Are you talking about turning on 'Smooth Draw' in the gfx_directx options and manually changing the window size? The window size setting isn't meant to reduce the zoom level to less than 1x, or to any other non-integer zoom level. I never occurred to me that that Smooth Draw is useful when scaling down graphics; I always leave it turned off. At less than 1x it actually looks very good, and terrible when disabled. So I guess we can add an Window Size Menu option to allow non-integer zoom levels.

There are definitely still problems with fullscreen and odd resolutions, but I don't want to spend a lot of time replicating your experiments right now. I think gfx_directx works better than SDL for that. Actually, my VirtualBox VM can't handle when gfx_directx fullscreens, one or the other gets stuck. (It's a VB bug, not a gfx_directx one.) So I can't easily test fullscreening on Windows.

Yes, textboxes need a lot of work.

My lack of updates isn't because I haven't been doing anything, but because I've been doing too many different things at once, and finishing nothing. So far I'm utterly failing at focusing on important things. I'll try to learn to write condensed summaries.
User avatar
Ichiro
Slime Knight
Posts: 238
Joined: Sat Sep 11, 2010 1:20 am
Location: john madden

Post by Ichiro »

TMC wrote:Are you talking about HamsterTools? Have you moved off GitHub? The (increasingly misnamed) OHRRPGCE Source Ports page only links to the Github page.
It's HamsterLib now, and I'm in the middle of a rewrite. The repository is at https://gitlab.com/lunarlabs/HamsterLib
Image
User avatar
Pepsi Ranger
Liquid Metal Slime
Posts: 1457
Joined: Thu Nov 22, 2007 6:25 am
Location: South Florida

Post by Pepsi Ranger »

TMC wrote:There are definitely still problems with fullscreen and odd resolutions, but I don't want to spend a lot of time replicating your experiments right now. I think gfx_directx works better than SDL for that. Actually, my VirtualBox VM can't handle when gfx_directx fullscreens, one or the other gets stuck. (It's a VB bug, not a gfx_directx one.) So I can't easily test fullscreening on Windows.
The engine still complains that you need gfx_sdl to display the affected resolutions properly, and use of the direct_x backend does nothing for custom resolutions.
Place Obligatory Signature Here
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Err, yes, it's not implemented yet, but when it is I expect it to work well :)

Re: HamsterLib: You've started over from scratch again? Hmm, then I guess it makes more sense to continue linking to the old project for now, but feel free to edit the wiki yourself.

---

Having separated the sprite editor from the sprite browser I can write a new spriteset browser/editor. This is the part that reads and writes the sprites to file, will handle sprites with variable numbers and sizes of frames, and contains the animation editor. (All unstarted.) I plan to make the editor totally slice-based and mouse enabled. (Slices aren't used much in Custom; I think the attack and textbox chain browsers and the full-screen text editor are the only slice-based editors/menus, aside from some hidden unfinished ones.)

I wrote some code just shy of 7 years ago for spritesets and animated sprites, but which I've never touched since and had mostly forgotten about.
(A SpriteSet is a bunch of frames plus animation definitions. You see, the engine doesn't currently use any data structure to represent a spriteset; instead a bunch of individual Frames are placed next to each other in memory in a C-style array, which is a pain for caching)

The animation stuff was not quite complete in the first place, and I ended up rewriting at least half; I was very close to giving up for the day when I finally got it working:

Image
(That's me pressing the I/A/W keys.) This is what the "spriteset editor" looked like 5 days ago, and it's still what it looks like today :/

Until I write an actual editor, the animations are hard coded like so:

Code: Select all

    WITH *ss->new_animation&#40;"idle"&#41;
      .append&#40;animOpFrame, frameSTAND&#41;    '0
    END WITH
    WITH *ss->new_animation&#40;"walk", "left"&#41;
      .append&#40;animOpFrame, frameSTAND&#41;    '0
      .append&#40;animOpWait, 2&#41;
      .append&#40;animOpFrame, frameSTEP&#41;     '1
      .append&#40;animOpWait, 2&#41;
      .append&#40;animOpRepeat&#41;
    END WITH
    WITH *ss->new_animation&#40;"attack", "left"&#41;
      .append&#40;animOpFrame, frameATTACKA&#41;  '2
      .append&#40;animOpWait, 2&#41;
      .append&#40;animOpFrame, frameATTACKB&#41;  '3
      .append&#40;animOpWait, 2&#41;
      .append&#40;animOpFrame, frameSTAND&#41;  '0
    END WITH
Nothing is completely decided yet (and we've had many long discussions on the mailinglist which never resulted in anything), but you can see some ideas here:

First, notice that the "walk" animation ends in "Repeat", so will continue until something happens to start a different animation, but "attack" doesn't. I think I will probably make all animations end by switching to the special "idle" animation if you don't end them in another way. (Or maybe you should have to do it manually?) Then the frameSTAND at the end of "attack" can be removed. Of course, you can make "idle" a repeating animation, or leave it completely blank so that the last frame from the previous animation remains shown (that's what the default idle animation for walkabouts will be).

Also, animations have names instead of ID numbers. When you create a new animation you'll be able to pick a name from a list with special meanings, or pick your own. But maybe I'll end up translating the names to ID numbers behind the scenes, so it's nothing but a small user interface difference.

Finally, the "left" is my idea for animation variants: multiple animations with the same name. If the desired variant is missing then the default variant is used. For example if the heroes attack from the left of the screen they'll use "attack right" . But existing games only have a builtin default "attack left" animation, so that one gets used instead. Likewise you only need to define one "cast" or "walk", etc, animation if it's non-directional, instead of 4 animations.
So instead of a "Hurt" hero/enemy frame, "hurt" would be a property of the hero/enemy sprite which is 'sticky' meaning it applies to all animations, and there could be "hurt" variants of any animations if you wanted.
But what happens if you want to play "walk left hurt" but only "walk left" and "walk hurt" are defined? Which to use? I haven't figured this out yet, but one solution is to make people write down the rules for picking the correct animation explicitly themselves with if rules placed in the default version animations. For example, your "walk" animation might be:

Code: Select all

walk&#58;
  if 'hurt'&#58;  play 'walk hurt'
  if 'left'&#58;  play 'walk left'
  if 'down'&#58;  play 'walk left'
  play 'walk right'
This sounds a bit like overthinking. Another idea is to get rid of the idea of 'hurt' and other variants, and keep only directional variants. Instead, have an option to change to a completely different spriteset when hurt, or on other conditions. However, hero spritesets already contain hurt and regular graphics together.
Last edited by TMC on Tue Jan 17, 2017 6:50 am, edited 2 times in total.
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

I don't have anything to add about these animation ideas, other than that they sound great, and I think you are on the right track! :)
User avatar
Pepsi Ranger
Liquid Metal Slime
Posts: 1457
Joined: Thu Nov 22, 2007 6:25 am
Location: South Florida

Post by Pepsi Ranger »

TMC wrote:I wrote some code just shy of 7 years ago for spritesets and animated sprites, but which I've never touched since and had mostly forgotten about.
I think this thread should be stickied as a constant reminder to TMC that he has plans that must be finished before other bread crumbs lead him off in other directions that gives us an engine that can tie the user's shoes but still not give the user the ability to set custom font sizes or use arrays.
Place Obligatory Signature Here
Post Reply