Post new topic    
Page «  1, 2, 3, 4  »
Red Slime
Send private message
 
 PostThu Jan 31, 2019 1:37 am
Send private message Reply with quote
Only thing I could think of that would make sense would be "viewport slice" since it's like you're making a viewported version of a drawn element, and technically you COULD make splitscreen views with the clamp command, which are commonly referred to graphically as viewports?
Metal King Slime
Send private message
 
 PostThu Jan 31, 2019 2:17 am
Send private message Reply with quote
Actually you seem to be thinking of the clipping, which is an existing feature separate from the clamping I was demonstrating. (I set the parent slice to "Clip Children")
Trying to come up with a distinct name for everything leads to a lot of names to remember, many usually synonymous! It's far worse in the source code, where there are many more names for internal things (e.g. I just invented "slice support")
Metal King Slime
Send private message
 
 PostThu Feb 14, 2019 3:35 am
Send private message Reply with quote
Still didn't finish the slice clamping feature... been jumping between many different things and not finishing half of them. Let's see...

As RMZ mentioned, joystick controls are now mapped to keyboard keys (up/left/down/right/esc/enter) by default, so that existing games with scripted controls can be played with a joystick. You can disable that with a bit.
There are only a few OHR games that use the joystick script commands. If that includes your game I'd like to hear whether this causes any problems.

Also, I think I never actually mentioned here on the forums that Fufluns has working joystick support again. Has had for half a year. Joysticks had been terribly broken for a decade or two.
It's not complete since there's no way to change which buttons are the use and cancel keys, which is a problem on some controllers with strange button numbering (XBox controller on Mac is a prominent example). I want to add a menu where players can change the button mapping (the Ctrl-J joystick calibration screen was remorselessly deleted) as well as add options in the editor for which controls can be mapped. E.g. maybe you want a button called Special that maps to the Shift key.

Making progress on Fufluns, I've finally re-implemented the ability to edit a whole spriteset as one frame. More spriteset browser improvements coming up.

Spent a long time investigating details of spawning processes on Windows, especially Win98. No changes yet but may lead to fewer windows popping up and resulting stuck keys.

Also implemented stack traces on Linux for crash debugging (not checked into SVN yet).

And lots more time wasting playing around with the smoothing algorithm. I would have added a simple option to enable it, but gfx_directx doesn't support it yet.
Metal Slime
Send private message
 
 PostFri Feb 15, 2019 9:07 pm
Send private message Reply with quote
What will the available game resolutions be for Fufluns?

Will there be support for 257 colors? maybe 16 million in the near future?

youre the best tmc, you know im only kiddering. it's amazing to see where the ohr is at technically
Liquid Metal Slime
Send private message
 
 PostFri Feb 15, 2019 11:31 pm
Send private message Reply with quote
I'm sure there's an upper bound to the resolution you can set, but you can set the dimensions yourself. TMC and I were playing around with running game.exe at 40x40, 16x zoom the other night. It's certainly ridiculous, but you have essentially complete freedom with it!
I can't write in cursive.
Metal King Slime
Send private message
 
 PostSat Feb 16, 2019 9:47 am
Send private message Reply with quote
Newsflash, press F1 to see the minimap in 16777216 glorious colors.
257+ colors may also turn out to be useful... elsewhere...

But max resolution is only 1280x960 because that should be enough for anyone, right??
(Min resolution is 10x10, because 20x20 may just be too much for a one-pixel adventure.)
Since the resolution is fixed, allowing a high resolution which might be larger than the screen is a problem; better to fill the whole screen by scaling up, or by running at a flexible resolution (if you're scripting a word processor instead of a game, anyway).
Metal Slime
Send private message
 
 PostSat Feb 16, 2019 8:22 pm
Send private message Reply with quote
WhAAT!!!!!!!!!!!!! brb i gotta see this

there's no way
Metal Slime
Send private message
 
 PostSat Feb 16, 2019 8:45 pm
Send private message Reply with quote
This is amazing.

60 frames a second.
720 widescreen support.

Vikings looks great. The 2 frame walk cycle is hilariously fast.

but

I tried to import a 1280x720 image and it was grayed-out. SO CLOSE. What's the point of teasing a modern day resolution if the biggest image we can import is only 320x200?

Also, only the minimap is in 24bit color? can you import images without using the palette? asking for a friend
Metal King Slime
Send private message
 
 PostSun Feb 17, 2019 3:18 am
Send private message Reply with quote
You can import 1280x720 images. The maximum size of a backdrop is 4096x4096, though maybe I should reduce that since many OpenGL ES implementations don't support textures that large. (And you can import PNG and (most) JPEG files now too, just realise they get decompressed on import... I should change that).
Maybe you were trying to import a tileset? Those are still limited to 320x200; I haven't gotten to that limitation yet. I don't think any of the other graphics importers will complain about large input images. If you can't figure out why the file is greyed out maybe there's an error message in c_debug.txt.

I'm going to fixed the crazy walk cycle soon.
Red Slime
Send private message
 
 PostSun Feb 17, 2019 9:56 pm
Send private message Reply with quote
"Editor editor" XD

My desk looks something like that, except it's plain to see that I'm not doing anything important.
Metal Slime
Send private message
 
 PostSun Feb 17, 2019 11:20 pm
Send private message Reply with quote
I wasn't using the nightly. It works as you say. Pretty amazing.

An oddity I've noticed: whenever I change the resolution, play the game in fullscreen, it crops the game window where I cannot see the edges of the map anymore. I can see them when the game is windowed. Using a 4k resolution. Am i missing a general setting to fix this, or is using higher resolutions means having to give up full screen functionality?
Metal King Slime
Send private message
 
 PostMon Feb 18, 2019 6:13 pm
Send private message Reply with quote
I haven't heard that one before! What's the game resolution?
If you're playing a non-320x200 game the engine would be using the gfx_sdl graphics backend, because the default on Windows (gfx_directx) doesn't even support non-320x200 yet - got to fix that. (You can press Ctrl-F8 in-game to check/change backend).
SDL 1.2 (used by gfx_sdl) has fairly crappy fullscreen support. gfx_sdl2 (SDL2) and gfx_directx are much better. gfx_sdl2 is still experimental and isn't compiled into standard builds but seems to work pretty well for playing games (however, better not to use it for Custom, as it doesn't handle manually resizing the window.)
You can get a gfx_sdl2-enabled build here: http://hamsterrepublic.com/ohrrpgce/nightly/ohrrpgce-win-sdl2-wip.zip
This is very recent, very few people have tested it - would like to get some testing! I want to switch to gfx_sdl2 as the default because it's better in so many ways. There's no Mac gfx_sdl2 build available yet.
Note, you can freely mix a gfx_sdl2 build of game.exe with a different build of custom.exe. Only the build date matters.
Metal Slime
Send private message
 
 PostMon Feb 18, 2019 8:30 pm
Send private message Reply with quote
Mouse based movement built in, mouse only controls, even with the menus, this is truly outrageous, tmc. am blown away

Here's my findings with sdl2-wip:

- testing the game in custom causes my video driver to have to restart (when setting the game to have a higher resolution)***

- no crash when using game.exe to run the same file, BUT it will only show 960x600 in fullscreen and crop the rest (1920x1200 actual but it looks to be doubling pixels, window's resolution is 3840x2160) with the visible portion aligned at the top left of the screen

- 640x360 is the largest 16:9 ratio i can get to work without issue, BUT in fullscreen the mouse is no longer aligned with the game, pixel for pixel

***in the crash report it says this:
Code:
3.0 lock_resolution()
3.0 setvideomode zoom=2 w*h = 640*400
3.1 set_resolution 1280*720

and that's it, using 720 as an example. the setvideomode gave me the idea to try a 640 or less, and that seems to work

pretty amazing stuff. i guess i'll have to settle for 360HD
Metal Slime
Send private message
 
 PostMon Feb 18, 2019 11:14 pm
Send private message Reply with quote
TMC!!!!!!!!!!!!

you absolute fiend

no games would run in anything but 320x200 suddenly, giving me a heart attack. long story short, i had to go to roaming AppData for the OHRRPGCE and delete it all. APPARENTLY settings between versions of the ohr don't play nice with each other. now time to make a game nobody will be able to play unless they can find this hidden folder and delete it

(also mouse pixel x/y return correct results in fullscreen with higher resolutions)
edit: no, no it doesn't Sad
Metal King Slime
Send private message
 
 PostTue Feb 19, 2019 5:51 pm
Send private message Reply with quote
OK, hold up...

The two lines you pasted from c/g_debug.txt aren't really interesting. You misinterpretered them. "setvideomode zoom=2 w*h = 640*400" just means that the program is running at 320x200 with 2x zoom. That's still the default on start-up. "set_resolution 1280*720" means it's switching from 320x200 to 1280*720. It's whatever comes after that that's actually interesting.

I've never seen or heard of problems with config files when running multiple engine versions But if you could only play games at 320x200, that sounds like you were stuck on gfx_directx (or even gfx_fb) for some reason, which certainly shouldn't happen. Did you get an error message? Could I see your g_debug_archive.txt file (these problems were all in Game, not Custom, right?) But you can change the gfx backend back to gfx_sdl with Ctrl-F8 if needed, which is indeed a setting saved in %APPDATA%/OHRRPGCE.

Mouse pixel positions are wrong in fullscreen? With which graphics backend? I'm getting lost.

What do you mean by "causes my video driver to have to restart"? Your monitor turns off and back on again? The game starts in a window, not fullscreen, when using Test Game, right?

Quote:
no crash when using game.exe to run the same file, BUT it will only show 960x600 in fullscreen and crop the rest (1920x1200 actual but it looks to be doubling pixels, window's resolution is 3840x2160) with the visible portion aligned at the top left of the screen

I don't quite follow - the monitor's display resolution was switched from 4K to 1920x1200, which displayed the top-left 960x600 of the game at double scale, but you had the game resolution set to higher than 960x600? For a start, I'm really surprised that SDL2 would change the monitor resolution, because I specifically ask it not to, while on the other hand SDL1 always does it.

But OK, gfx_sdl2 definitely is broken in quite a few ways, I found a few myself.
Maybe I could fix gfx_sdl in fullscreen on 4K instead, but I don't have a monitor to test with.
Display posts from previous:
Page «  1, 2, 3, 4  »