Yet another OHRRPGCE dev blog
Moderators: Bob the Hamster, marionline, SDHawk
Yet another OHRRPGCE dev blog
So, my last dev blog petered out, because I tried to give it a narrow scope of graphics and animations, and then mostly didn't work on that. Also I made monolithic posts instead of regular updates.
I've been doing heaps of work on the engine in the last year, but mostly only mentioning it in IRC or Discord. Better to be more public. People often never find out about new features which are only mentioned in whatsnew.txt and nowhere else, because whatsnew is too long, too much at once, and totally lacking in jokes (or maybe you used nightlies and didn't reread whatsnew when a stable version is released - unfortunately we don't always add new things to the bottom!)
I'm going to follow James' example, creating a new thread for particularly interesting new features, and post the rest here.
The things at the top of the TODO list are HotOHR requests and finally finishing the blockers for the horribly delayed [s]Fuffle[/s] (edit: I mean Fufluns... Freudian slip!) release... in no particular order. Overriding all else are things started on an impulse... which nearly everything, explaining why the release is so late.
What's new?
You can now copy/paste item definitions, in the individual item editor. I even added undo, because I know how horribly annoying accidentally pasting the wrong tile or spriteset is (I really need to add undo there!)
But it would be nice if you could copy/paste directly in the item browser (the slice-based "thing browser"). I'd really like all the thingbrowsers to support copy/paste, but that's a different project.
Oh... my TODO list actually read "itemedit: add add-new menu with 'copy existing' option". *grumble* guess I won't mark that off
I've been doing heaps of work on the engine in the last year, but mostly only mentioning it in IRC or Discord. Better to be more public. People often never find out about new features which are only mentioned in whatsnew.txt and nowhere else, because whatsnew is too long, too much at once, and totally lacking in jokes (or maybe you used nightlies and didn't reread whatsnew when a stable version is released - unfortunately we don't always add new things to the bottom!)
I'm going to follow James' example, creating a new thread for particularly interesting new features, and post the rest here.
The things at the top of the TODO list are HotOHR requests and finally finishing the blockers for the horribly delayed [s]Fuffle[/s] (edit: I mean Fufluns... Freudian slip!) release... in no particular order. Overriding all else are things started on an impulse... which nearly everything, explaining why the release is so late.
What's new?
You can now copy/paste item definitions, in the individual item editor. I even added undo, because I know how horribly annoying accidentally pasting the wrong tile or spriteset is (I really need to add undo there!)
But it would be nice if you could copy/paste directly in the item browser (the slice-based "thing browser"). I'd really like all the thingbrowsers to support copy/paste, but that's a different project.
Oh... my TODO list actually read "itemedit: add add-new menu with 'copy existing' option". *grumble* guess I won't mark that off
Last edited by TMC on Mon Dec 24, 2018 6:35 am, edited 6 times in total.
Rewrote our hash table implementation. The new implementation is slower, uses more memory, is much more code, and has worse asymptotic complexity for some operations. Aside from that, it's far better than the old one, which was so unusable it was only used in two places.
If you're wondering why OHRRPGCE development has been so slow for the last month or so, it's partially because my desk looks like this. Also I got sidetracked, stuck and ran out of patience before finishing several things I started on in that time. But hopefully you hear about them soon.
If you're wondering why OHRRPGCE development has been so slow for the last month or so, it's partially because my desk looks like this. Also I got sidetracked, stuck and ran out of patience before finishing several things I started on in that time. But hopefully you hear about them soon.
Last edited by TMC on Tue Jan 01, 2019 10:44 pm, edited 1 time in total.
- Bob the Hamster
- Lord of the Slimes
- Posts: 7684
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
I'm building a MPPT solar inverter (which converts from variable-voltage DC to AC), which is a bit of a crazy project for safety reasons. If my prototype works, I'm going to have to replace all the dubious cheap capacitors I bought on ebay with high quality ones, if I don't want it to explode after a few months. Most of the work is on paper and in a simulator. I'm learning a huge amount of electrical engineering in the process.
Last edited by TMC on Wed Jan 02, 2019 11:35 pm, edited 3 times in total.
I thought I'd finished with the hash table, but then I decided to write some testcases. Not only did I find bugs, but I realised the whole design was flawed. So more rewriting; I changed it a couple more times before finally being happy with it. Even filed a FreeBASIC bug. Tremendous waste of time, but now back to more meaningful stuff. I find that an awful lot of time spent programming is consumed by those sorts of unforeseen major difficulties.
Added a "find color" command because Gizmog asked about it, and it only took two lines of code to add. (Writing documentation and testcases was 98% of the work.)
Then fixed some bugs. (One of them, wasted half an hour thinking the compiler was miscompiling my code.) Finally solved the "warning: leaked sprite / sprite_empty_cache: corruption" errors that've often been printed to the end of g_debug.txt for years now. It was a silly mistake: we checked whether all sprites had been freed actually deleting all slices! So if anyone still sees such a warning with the next nightly build I'd like to hear about it.
Added a "find color" command because Gizmog asked about it, and it only took two lines of code to add. (Writing documentation and testcases was 98% of the work.)
Then fixed some bugs. (One of them, wasted half an hour thinking the compiler was miscompiling my code.) Finally solved the "warning: leaked sprite / sprite_empty_cache: corruption" errors that've often been printed to the end of g_debug.txt for years now. It was a silly mistake: we checked whether all sprites had been freed actually deleting all slices! So if anyone still sees such a warning with the next nightly build I'd like to hear about it.
Last edited by TMC on Fri Jan 11, 2019 2:38 pm, edited 3 times in total.
I've been working on cleaning up text box code, laying groundwork for larger boxes.
NOT coming soon to an engine release temporally near you!
Trivia: I only recently noticed that James usually (consistently?) writes 'text box' instead of 'textbox'. I've always been calling them textboxes. So any inconsistency in the engine/documentation is probably my fault.
NOT coming soon to an engine release temporally near you!
Trivia: I only recently noticed that James usually (consistently?) writes 'text box' instead of 'textbox'. I've always been calling them textboxes. So any inconsistency in the engine/documentation is probably my fault.
- Bob the Hamster
- Lord of the Slimes
- Posts: 7684
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
I was not aware that I wrote "text box" more often than "text box". I guess I like to type fast without thinking ;)
(EDIT: I wrote "textbox" the second time in the line above, but autocorrect happened. That explains it for forum posts, but not for source code.)
I have no strong opinion about which is more correct.
What do we have left that seems like a Fufluns blocker?
(EDIT: I wrote "textbox" the second time in the line above, but autocorrect happened. That explains it for forum posts, but not for source code.)
I have no strong opinion about which is more correct.
What do we have left that seems like a Fufluns blocker?
Last edited by Bob the Hamster on Thu Jan 17, 2019 10:56 am, edited 1 time in total.
- Pepsi Ranger
- Liquid Metal Slime
- Posts: 1460
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
To clarify, I didn't mean that Fufluns isn't really close, I meant that I'm not about to replace the SAY textbox file format, which needs to happen before we can get larger textboxes (and probably customisable horizontal width too). But I am working on automatically "un-wrapping" and re-wrapping lines of text around portrait boxes, which will be helpful to let you adjust the width of an existing box.
I was looking through the names of menu items and documentation, which had mostly been written 20 years ago, and found that James pretty consistently wrote "text box". Maybe he doesn't anymore.
Fufluns is held up by one part bugs, one part lost features that ought to be restored, and one part performance issues.
The bugs that I'm concerned about include a couple of crashes that still haven't been fixed, especially Fenrir's report that copy-pasting text always crashes. I also need to look into what Nathan said about broken textbox conditionals which apparently means that a post-Etheldreme bugfix actually broke something. Better fix the uninitialised-enemy-appending bug too.
To help figure out Fenrir's crashes and generally have a less buggy release I want to finally finish adding CrashRpt. (I need to dynamically load the library, so we can run if it's missing.) Not actually a blocker.
I want to add back to the spriteset editor the ability to edit a whole spriteset as one frame - people are complaining - and also the names of frames are missing (I started on that). That is a blocker. Plus make "Add new spriteset" less annoying to select.
I'm also concerned by how long the spriteset editor and thingbrowsers can take to load in huge games. (Opening and closing a file thousands of times is slow on Windows and fast on Unices, and potentially far, far slower if you have a virus scanner installed!) Trying an optimised engine build on a 4-year-old copy of POWERXE.rpg, the most painful thing is the initial load of the walkabout spriteset editor, (~4 seconds under Linux, ~15 seconds under Windows XP!). Since my sprite cache fix a few days ago, the sprite cache doesn't get dumped after you edit one spriteset, so on subsequent loads it's only 3 seconds on Windows.
Also, on Windows the SFX browser takes 8 seconds to load, the textbox browser 3 seconds, the music browser 2 seconds. All these menus take less than 1 second under Linux.
But I guess this isn't a blocker since we could just tell Pepsi Ranger not to upgrade to nightlies/Fufluns, and he's used to waiting a minute for scripts to compile anyway : P
I was looking through the names of menu items and documentation, which had mostly been written 20 years ago, and found that James pretty consistently wrote "text box". Maybe he doesn't anymore.
Fufluns is held up by one part bugs, one part lost features that ought to be restored, and one part performance issues.
The bugs that I'm concerned about include a couple of crashes that still haven't been fixed, especially Fenrir's report that copy-pasting text always crashes. I also need to look into what Nathan said about broken textbox conditionals which apparently means that a post-Etheldreme bugfix actually broke something. Better fix the uninitialised-enemy-appending bug too.
To help figure out Fenrir's crashes and generally have a less buggy release I want to finally finish adding CrashRpt. (I need to dynamically load the library, so we can run if it's missing.) Not actually a blocker.
I want to add back to the spriteset editor the ability to edit a whole spriteset as one frame - people are complaining - and also the names of frames are missing (I started on that). That is a blocker. Plus make "Add new spriteset" less annoying to select.
I'm also concerned by how long the spriteset editor and thingbrowsers can take to load in huge games. (Opening and closing a file thousands of times is slow on Windows and fast on Unices, and potentially far, far slower if you have a virus scanner installed!) Trying an optimised engine build on a 4-year-old copy of POWERXE.rpg, the most painful thing is the initial load of the walkabout spriteset editor, (~4 seconds under Linux, ~15 seconds under Windows XP!). Since my sprite cache fix a few days ago, the sprite cache doesn't get dumped after you edit one spriteset, so on subsequent loads it's only 3 seconds on Windows.
Also, on Windows the SFX browser takes 8 seconds to load, the textbox browser 3 seconds, the music browser 2 seconds. All these menus take less than 1 second under Linux.
But I guess this isn't a blocker since we could just tell Pepsi Ranger not to upgrade to nightlies/Fufluns, and he's used to waiting a minute for scripts to compile anyway : P
Last edited by TMC on Thu Jan 17, 2019 11:59 pm, edited 1 time in total.
- Bob the Hamster
- Lord of the Slimes
- Posts: 7684
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
- Pepsi Ranger
- Liquid Metal Slime
- Posts: 1460
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
Too true.TMC wrote:But I guess this isn't a blocker since we could just tell Pepsi Ranger not to upgrade to nightlies/Fufluns, and he's used to waiting a minute for scripts to compile anyway : P
I haven't used a nightly since about two codenames ago, so I'm fine. Most of my work these days is in rewriting scripts in Scrivener, so I'm not even using Custom that much at the moment. There's a good chance you'll finish Fufluns before I'm back to work compiling scripts on a continuous basis (and I've optimized so much the last couple of years that I've done my own compiling speed-up).
It'll be a while still before I put steady work back into POWERXE. When I do, I'll be working on script rewrites for that, so I'll be able to get that going a little faster, as well.
Place Obligatory Signature Here
- FnrrfYgmSchnish
- Metal Slime
- Posts: 741
- Joined: Thu Jun 18, 2009 4:37 am
- Location: Middle of Nowhere
Good to hear -- I was definitely missing the CTRL+F edit-everything-at-once mode after I switched to one of the more recent nightlies that didn't have it!I want to add back to the spriteset editor the ability to edit a whole spriteset as one frame - people are complaining - and also the names of frames are missing (I started on that). That is a blocker. Plus make "Add new spriteset" less annoying to select.
Also, what happened to being able to delete spritesets? It doesn't seem possible in the recent nightlies, not sure how long it's been that way. Used to be CTRL+Backspace or something like that would delete everything after the currently selected one, like in most of the other editors. I would say that would be an even bigger deal than the inability to edit them all at once, especially now that it's possible to add a new spriteset with oddly sized frames and you might realize afterward that you needed a bigger/smaller size (though, being able to change the size of sprites after they're created would make that easier to work around... is that possible, or not yet?)
FYS:AHS -- Working on Yagziknian NPC walkabout sprites
Oh yes, deleting spritesets is another thing I need to re-implement.
And shamefully I've yet to rectify the glaring omission of a way to resize an existing spriteset. I will definitely be adding that, maybe later today.
And I now remember a few other things caused by variable-sized spritesets that ought to be fixed too: attacks are mispositioned, weapons can be mislayered (they might appear behind instead of in front), battle cursors on heros are mispositioned (?), the spriteset editor doesn't scroll horizontally so you can't see large spritesets, portrait boxes are the wrong size, NPCs are mispositioned in the map editor, and the hero editor sprite preview needs update. Some of these matter more than others; I'm not too concerned about editor graphical glitches.
Yesterday I fixed the weapon handle/hero hand positioning editors and other bug hunting. Today I'm working on a proper crash reporter, to make it easier for us to solve crashes.
Then, having done some token work on Fufluns, I can get back to the other thing I've been working on - and talking about adding for years - translations!
Also, I realise there are far more blocker bugs than I thought. The tag menu autoset info box crashes, the Sell menu is horribly broken when max inventory size is small, upgrading (filling in) missing UI colors is broken, there's a minimap crash that's probably a problem in nightlies, and if mouse controls are disabled, the first menu item in some menus is always highlighted. That's not to mention about 5 more crash bugs that aren't really blockers. I think these are the buggiest nightlies we've had in many years.
Edit: Finally updated Bughunters League Table with 17 new bugs; Feenick leapfrogs to 2nd place!
And shamefully I've yet to rectify the glaring omission of a way to resize an existing spriteset. I will definitely be adding that, maybe later today.
And I now remember a few other things caused by variable-sized spritesets that ought to be fixed too: attacks are mispositioned, weapons can be mislayered (they might appear behind instead of in front), battle cursors on heros are mispositioned (?), the spriteset editor doesn't scroll horizontally so you can't see large spritesets, portrait boxes are the wrong size, NPCs are mispositioned in the map editor, and the hero editor sprite preview needs update. Some of these matter more than others; I'm not too concerned about editor graphical glitches.
Yesterday I fixed the weapon handle/hero hand positioning editors and other bug hunting. Today I'm working on a proper crash reporter, to make it easier for us to solve crashes.
Then, having done some token work on Fufluns, I can get back to the other thing I've been working on - and talking about adding for years - translations!
Also, I realise there are far more blocker bugs than I thought. The tag menu autoset info box crashes, the Sell menu is horribly broken when max inventory size is small, upgrading (filling in) missing UI colors is broken, there's a minimap crash that's probably a problem in nightlies, and if mouse controls are disabled, the first menu item in some menus is always highlighted. That's not to mention about 5 more crash bugs that aren't really blockers. I think these are the buggiest nightlies we've had in many years.
Edit: Finally updated Bughunters League Table with 17 new bugs; Feenick leapfrogs to 2nd place!
Last edited by TMC on Sun Jan 20, 2019 3:36 am, edited 2 times in total.
I've implemented a proper crash handler on Windows using CrashRpt. This is a utility which sends crash reports (including fatal errors) over the internet so that we can solve them.
It requires some extra files in the support/ directory, so doesn't work if you distribute your game to people without a copy of the OHRRPGCE installed. So I'm currently working on a backup handler which doesn't require any separate files, and works on Mac and Linux. I've got file compression and network code working so far. Later, we can reuse that to add some networking script commands :)
It requires some extra files in the support/ directory, so doesn't work if you distribute your game to people without a copy of the OHRRPGCE installed. So I'm currently working on a backup handler which doesn't require any separate files, and works on Mac and Linux. I've got file compression and network code working so far. Later, we can reuse that to add some networking script commands :)
Last edited by TMC on Sat Jan 26, 2019 5:28 am, edited 1 time in total.
Bird requested Windows 98 support as his HotOHR request, but I went a little further all the way to the original release of Windows 95.
You don't even have to install any hacks like KernelEx to get it to run. (Even with KernelEx, Win98 hasn't worked since Beelzebufo).
Don't be misled by this screenshot, Test Game doesn't work on 95/98/ME.
Virtually everything else works on Windows 98, including the Distribute Game menu and importing/transcoding audio files, but there are a few problems on Windows 95, like hspeak.exe and the scroll wheel not working. I tested on 95 and 98SE. I also have audio problems, but I think they're the fault of VirtualBox.
Windows 98 is actually pretty nice to run in a VM. Can set the resolution to 1600x1200, run a dozen programs in 128MB RAM, and everything is fast.
...
Also, I've been working on an option to clamp a slice to the edge of its parent. It's just what you want for an auto-scrolling text input field like in this gif.
Unfortunately we already have a "clamp slice" command, but this works a bit differently because it doesn't permanently change the slice's X/Y position, it changes how it gets translated to screen position, like anchor and align points. Maybe I can think up some other name for it. Maybe I shouldn't.
Oh yeah, also been working on other stuff... no, not Fufluns.
You don't even have to install any hacks like KernelEx to get it to run. (Even with KernelEx, Win98 hasn't worked since Beelzebufo).
Don't be misled by this screenshot, Test Game doesn't work on 95/98/ME.
Virtually everything else works on Windows 98, including the Distribute Game menu and importing/transcoding audio files, but there are a few problems on Windows 95, like hspeak.exe and the scroll wheel not working. I tested on 95 and 98SE. I also have audio problems, but I think they're the fault of VirtualBox.
Windows 98 is actually pretty nice to run in a VM. Can set the resolution to 1600x1200, run a dozen programs in 128MB RAM, and everything is fast.
...
Also, I've been working on an option to clamp a slice to the edge of its parent. It's just what you want for an auto-scrolling text input field like in this gif.
Unfortunately we already have a "clamp slice" command, but this works a bit differently because it doesn't permanently change the slice's X/Y position, it changes how it gets translated to screen position, like anchor and align points. Maybe I can think up some other name for it. Maybe I shouldn't.
Oh yeah, also been working on other stuff... no, not Fufluns.
Last edited by TMC on Wed Jan 30, 2019 1:01 pm, edited 3 times in total.