Post new topic    
Page «  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  »
Metal Slime
Send private message
 PostWed Feb 20, 2019 6:39 pm
Send private message Reply with quote
will try to clear things up

most every crash in the debug occurred via 'test game' in custom, have been using about 4 or so ohr directory/installs seeing if i could work pass this, attaching the g_debug_archive from the sdl2 install... slime salad says i am not allowed to post txt files...

it really did end after what i pasted, nothing interesting past that. here's what the other variation was:

0.0  OHRRPGCE wip 20190217.10978 gfx_sdl2+directx+fb/music_sdl2 FreeBASIC 1.05.0 (01-31-2016) GCC 5.3.0 x86 pdb  Built on vampirecell -g -gen gcc Win32 32-bit
 0.0  exepath: C:\Games\ohr\OHRRPGCE SDL2, exe: C:\Games\ohr\OHRRPGCE SDL2\game.exe
 0.0  orig_dir: C:\Games\ohr\OHRRPGCE SDL2
 0.0  curdir: C:\Games\ohr\OHRRPGCE SDL2
 0.0  Runtime info:   music_sdl2, SDL 2.0.7, SDL_Mixer 2.0.2  Windows 6.1.7601 (7/Server 2008 R2) Service Pack 1
 0.0  Reading commands from master channel '\\.\pipe\ohrrpgce_lump_updates_testing_78553'
 0.0  Spawned from Custom ()
 0.0  Initialising gfx_directx...
 0.0  gfx_directx: gfx_Initialize()...
 0.1  gfx_directx: Adapter: AMD Radeon(TM) RX 560 Series
 0.1  gfx_directx: Driver: aticfx32.dll
 0.1  gfx_directx: IDirect3DDevice9 object created as hardware device.
 0.1  gfx_directx: D3DXSaveSurfaceToFile() successfully loaded.
 0.2  gfx_directx: Scanning for newly-attached joysticks
 0.2  gfx_directx: Joysticks supported.
 0.2  gfx_directx: Initialization success
 0.2  Starting IO polling thread
 0.2  Resolution changing not supported
 0.2  music_sdl2, SDL 2.0.7, SDL_Mixer 2.0.2 (48000Hz, Music decoders:WAVE,OGG,MAD,MODPLUG,NATIVEMIDI,MOD,MIDI,MP3 Sample decoders:WAVE,AIFF,VOC,MOD,MID,OGG,MP3)
 0.2  Setting default window settings...
 0.2  gfx_directx: setwindowed(-1)
 0.2  gfx_directx: gfx_SendMessage 8 -1 0
 0.2  Setting graphics scaling to x2 change_windowsize=-1
 0.2  gfx_directx: gfx_SendMessage 3 640 400
 0.2  Received message from Custom: V OHRRPGCE,4,10978,OHRRPGCE wip 20190217
 0.2  Received message from Custom: G C:\Games\ohr\OHRRPGCE SDL2\test.rpg
 0.2  Received message from Custom: W C:\Users\Blu\AppData\Roaming\OHRRPGCE\working0.tmp\
end_debug: no debug/error messages during startup (skipping rest of startup)

 0.2   ----Loading C:\Games\ohr\OHRRPGCE SDL2\test.rpg----
 0.2  curdir: C:\Games\ohr\OHRRPGCE SDL2
 0.2  tmpdir: C:\Users\Blu\AppData\Local\Temp\ohrrpgce20190218172257.946.tmp\
 0.2  settings_dir: C:\Users\Blu\AppData\Roaming\OHRRPGCE
 0.2  savedir: C:\Games\ohr\OHRRPGCE SDL2\test.saves
 0.3  Name:
 0.3  plotscr.hsd version:
 0.8  lock_resolution()
 0.8  Attempting to switch to gfx_sdl for flexible resolution
 0.8  switch_gfx sdl
 0.8  gfx_directx: gfx_Shutdown()...
 0.8  gfx_directx: Shutdown complete
 0.8  ! ERROR: Invalid gfx backend sdl


Mouse pixel positions are incorrect with gfx_sdl2. I've seen this before in other applications, it doesn't account for the stretch like it does when windowed. So in one sense, it is super accurate to the actual display, but not in the logically desired way to the game's base resolution.


My video driver crash: I started with using the nightly. Then I switched to the link for sdl2 you provided. This is when any resolution setting besides 320 would do this when running it through custom or game.exe: the window would appear, windows would freeze for a few seconds, screen would go black and then windows would inform me the video driver shut down and had to restart, and then it would stall again, finally asking to send a bug report.

Deleting the %APPDATA%/OHRRPGCE fixed this, but I still cannot run any resolution higher than 640x360 (haven't tested pixel by pixel, so i might be off, 720 def does not work)


still making muh game in good faith you'll figure it all out and we'll be able to play it in full screen later, the higher res makes it fun again for me, is much appreciated
Metal King Slime
Send private message
 PostThu Feb 21, 2019 10:18 am
Send private message Reply with quote
OK, thanks. This 'Invalid gfx backend sdl' error is easy fix, silly mistake. I see that it crashes outright while trying to show an error message, at for me. Didn't you see the crash handler pop up when it crashed? It doesn't appear for all error messages. (This error is actually meant to be recoverable)

I have no clue what the video driver crash was caused by, but I place blame on nVidia for that. You have an nVidia GPU, right? I'll take any excuse to diss nVidia, because I hate their Linux drivers.
Of course, it was probably triggered by trying to do something weird and invalid on our end.
The gfx_sdl2 code to do with resolution is so far from finished that I'm [amazed it works at all and] expect the crash will simply disappear once it is finished. Ditto the mouse positioning.

My plan for the nearterm is to finally implement variable resolution support in gfx_directx.

Wait, so both gfx_sdl2 and the default gfx_sdl don't show the whole image in fullscreen when the resolution is higher than 640x360 (or at least not 720 wide), is that right? Did they both cut off the image in the same way? That's really weird that they behave the same since SDL and SDL2 handle fullscreening very differently ... maybe there's something I copy-pasted from gfx_sdl to gfx_sdl2 that's bad (but most of that stuff is different).
Metal King Slime
Send private message
 PostThu Feb 21, 2019 6:41 pm
Send private message Reply with quote
Working on something. Sometimes people make loose remarks on discord or elsewhere and I get motivated.

Probably won't be done for Fufluns. Or maybe I should say Fufluns won't be done in time.
Metal Slime
Send private message
 PostThu Feb 21, 2019 7:04 pm
Send private message Reply with quote
W... Wha.. I dont... whathefuck... *wheeze*
Metal Slime
Send private message
 PostThu Feb 21, 2019 7:12 pm
Send private message Reply with quote
That's incredible! will have to come on discord at some point and make lots of loose remarks

and I'd like to help you further, but i'd like to wait until after I finish the game i'm making with the sdl2 version, dont want to have something break and kill my motivation just yet
Liquid Metal King Slime
Send private message
 PostThu Feb 21, 2019 7:20 pm
Send private message Reply with quote
Oh, my! That rotation looks really good!
Metal King Slime
Send private message
 PostFri Feb 22, 2019 12:17 pm
Send private message Reply with quote
Oh you're all just traumatised by 20 years of being told "No"!
Turns out that rotating sprites is pretty fast, even on a CPU and generating non-SIMD code that will run on a 486 (as we do), if you just use the simplest implementation which does no filtering. I don't have a terribly new or fast CPU, but can draw 20 rotated 320x200 backdrops and still hit 60fps. In other words, this should have been added long, long ago.

So what's interesting is to have an option for slower (we're talking 10x or more) zooming/rotating which does some filtering.
The rotozoom code I'm using, derived from SDL_gfx, has a bi-linear smoothing option when running in 32-bit color depth:

(The way that the image moves by half a pixel when smoothing is enabled is a very common bug in image filtering code; I'll fix it)

But bi-linear is pretty poor when shrinking heavily rather than expanding images, that's one reason GPUs use minimapped textures.
I already wrote my own 32-bit shrinking routine ("surface_scale", used in the backdrop browser); here's a comparison between unfiltered, bilinear, and surface_scale:

SDL_gfx doesn't have any kind filtering for 8-bit rotozoom, so I'm going to implement one myself. Namely, a variant on the well-known RotSprite, but faster. I think I'll have three rotozoom quality levels - the max level can be used in the sprite editor and when you're not rotating a whole backdrop.

Also looks like I need to do more work on the gif encoder, it generated huge gifs in 32-bit mode; I made these with gifsicle instead.

But actually, I'll been working on squashing bugs today.
Metal King Slime
Send private message
 PostMon Feb 25, 2019 12:52 pm
Send private message Reply with quote
Charbile: could you respond to this?
TMC wrote:
Wait, so both gfx_sdl2 and the default gfx_sdl don't show the whole image in fullscreen when the resolution is higher than 640x360 (or at least not 720 wide), is that right? Did they both cut off the image in the same way? That's really weird that they behave the same [...]

I'm also curious about
TMC wrote:
I see that it crashes outright while trying to show an error message, at least for me. Didn't you see the crash handler pop up when it crashed?


Someone in the chatroom mentioned asesprite's sprite rotation function, and I grew mad with envy and --

-- soon enough my anger was overflowed by the sprite editor's unmanageable and incorrigible code, especially the pain of adding a new button or moving an existing one (it might actually be easier if all the positions were hardcoded...)

Not shown: all the bugs. Lots of missing bits too. Ugh, this will *definitely* not be in Fufluns. Besides, I really need to implement a better rotation/scaling algorithm, otherwise the results are so poor (as you can see) that the convenience of not needing an external program may not make up for it. I've been thinking in detail about it and believe I can improve on RotSprite, because there appears to be a logical error in its design which I know how to fix. Also, RotSprite isn't designed for high zoom levels anyway.
Liquid Metal King Slime
Send private message
 PostMon Feb 25, 2019 3:51 pm
Send private message Reply with quote
Dang, that is so cool! I would get a lot of use out of that feature.

And yes, I am sorry the Sprite editor code is so bad. A lot of it is even older than the OHRRPGCE itself

Will it also work on mark/clone selections?
Metal King Slime
Send private message
 PostTue Feb 26, 2019 5:08 am
Send private message Reply with quote
I haven't implemented transforming clone selections, but I will. I also haven't add mouse controls - I wanted sub-pixel control, like the ellipse tool.

Plenty of work has already gone into cleaning up the sprite and tile editor code over the years, so overall it's not so bad, but the UI code never got any attention. I'd want to refactor the tools to OO-style, so all the code for each tool goes in one place, and put in a decent abstraction layer for defining buttons and controls. I now definitely don't want to try to implement 256-color sprites without first cleaning up the UI code.
Metal Slime
Send private message
 PostFri Mar 01, 2019 2:49 am
Send private message Reply with quote
exhibit C
exhibit B
exhibit A
TMC wrote:
Charbile: could you respond to this?

A) what happens when running gfx_sdl2 with ohr set to 1280x720 -- is this the crash handler you mean?

B) what happens at the bottom right in windows EVERY time i run a game :|

C) using a nightly, which only has gfx_sdl set, the windowed game displays correctly, but when entering fullscreen, it crops the edges. using a 50x50 tile map as a test

deleting the roaming app settings helped a lot of those panic-mode reports i gave earlier, so this is where i'm at now. am happy to test more for you, just say the word
Metal King Slime
Send private message
 PostFri Mar 01, 2019 10:02 pm
Send private message Reply with quote
Ah, OK, thanks.

You know, you can dismiss those crash reports by clicking on the pop up. And you could have not selected "Close the program and store the report to send later" if you had no intention to send later! But if no one is actually going to want to withhold and send later I guess I may just remove the option to do so. But I was trying to make it easier to click SEND than to do nothing :|

OK, time for me to go fix gfx_directx...
Metal King Slime
Send private message
 PostThu Mar 21, 2019 9:22 pm
Send private message Reply with quote
Yikes, it's been a few weeks since I gave an update here. I've been a bit more focused on finishing Fufluns, but still many distractions. There are still ~25 new-in-nightlies bugs unfixed.

-Fixed all the gfx_sdl2 bugs Charbile reported. I'm not aware of any more significant gfx_sdl2 bugs, so it's probably usable on Windows, GNU/Linux and Unix now. (No Mac build yet.) In future (not Fufluns) it'll become the default.

-Option to hide "x1" count for singular items in inventory slots (Always, Never, Only unstackable items)

-Added "Press ESC to cancel/change a hero's attack" turn-based battle bitset (default on) (This was added for Foxley's RGC game, doesn't really have much other use)

-"set/get selected child" convenience wrapper commands

-Spent a few days on a tool to automate the processing of crash reports. This is done, it's very nice, already resulted in learning of and solving one previously unknown crash. Alas, whoever reported that didn't provide their name, so gets no bughunter points

-A couple other significant bugfixes: 4-bit PNGs not importing correctly, and the error when typing to the end of an 8-line textbox

-Dozens of unimportant bugfixes and minor changes

-A bunch of experiments and unfinished features, more on those later
Metal King Slime
Send private message
 PostWed Apr 17, 2019 12:12 am
Send private message Reply with quote
I'm terrible at timely updates.

SwordPlay picked up the source code and has been playing around with it, which I'm really pleased to see; I've been giving him guidance. He compiled the OHRRPGCE for his Raspberry Pi; that hasn't been done in years. Now that it's not just me, we have an #engine_dev channel in the SS Discord server.

The first thing he's done is implement hero MP meters!

there are new UI colors. The meters are disabled by default in existing games.
He's also been experimenting with modifying some builtin menus for low resolutions.

-Foemap Stats and Enemy Usage menus

-I realised that the option to dither an image when importing (new in nightlies since a year ago) was using a very bad color distance metric, and that's why it produced such poor results.

Before/after pairs compared with no dithering:

(Backdrops by Fenrir)

While I was fixing that I also made it possible to reduce the amount of dithering noise, and to preview the results before you select an option:

-Transparent rect slices. These aren't actually used anywhere yet (but here's a preview of what it might look like). Works by doing a nearest-color search of the master palette, so it doesn't look very good if you do a fade. Maybe if I used dithering?

-Added "Camera following a hero/NPC centers on: tile/sprite/sprite minus Z" setting. A few people have complained that when using larger walkabouts, switching from "camera follows hero" to "focus camera" or other tile/pixel based camera-centered caused the camera to jump. This fixes that.

-Fixed the Quit menu for larger sprites

-Many errors that used to silently print to c/g_debug.txt now show an error message instead. Still hundreds of silent error conditions

-Added "Ignore harmtiles" vehicle bit

-Various uninteresting bugfixes and tweaks, like the airbrush tool

-A lot of code cleanup recently

-Little progress on Fufluns :( I thought it would be released last month. Surely this month?
Metal King Slime
Send private message
 PostSun Jul 28, 2019 3:33 pm
Send private message Reply with quote
Err... I haven't done much work on the engine in the last three months (that's an entire release cycle~!!) but I've been even lazier about posting here about it.

Highlights (few as they are):

You can now add a new battle and ehro formations as copies of existing ones.

Press G in NPC placement mode to select the NPC ID under the cursor.*

Added "read wall bit" and "write wall bit" convenience wrappers around "read/write pass block".*

Wasted time making the file browser sort numbers correctly.

Fixed a bug where menu items could permanently vanish from the menu editor if set to "hide if disabled". They will reappear now.

The enemy cursor position was wrong in the enemy editor.

And various other bugfixes (including a few crashes) and a lot of uninteresting stuff.

I did work on some other things not finished yet...
Having added transparent rectangles, I worked on alpha transparency for sprites and map layers. It's close to done but I've decided to wait until after Fuflun. I've implemented it in both 8-bit and 32-bit color modes:

I find most 8-bit alpha dithering results look much better than these clouds, but you'll have to wait for 32-bit color mode for it to look really nice. It needs more work (eg screen fades don't work).
I notice that dithering looks far better on a CRT than an LCD monitor! Especially at 1x zoom, the difference is awful.

It's now crunch time for Fufluns!

*Not in nightlies until tomorrow
Display posts from previous:
Page «  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  »