Chaosforge Forum

  • August 16, 2022, 13:36
  • Welcome, Guest
Please login or register.

Login with username, password and session length

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Shadowfury333

Pages: [1] 2
Bug Reports / Re: Vulkan Rendering Glitch
« on: August 25, 2019, 13:33 »
Windows 7 Professional SP1, and so far I've only had it happen once

Bug Reports / Vulkan Rendering Glitch
« on: August 24, 2019, 20:13 »
I started up JH just now with the Vulkan Renderer, and got weird speckles everywhere. This was a bit random...and now I realize I had a log I could have grabbed as well, but I opened the game up to double-check if this was a consistent thing before remembering that.

My specs:

nVidia GeForce GTX 970, driver version
Intel Core i7-6700K

There's always the pre-order page. It doesn't have all the tiers of the Kickstarter, but it is an option.

Very reminiscent of Infra Arcana. Seems appropriate to me.

Discussion / Re: D**mRL Run video to try to promote Jupiter Hell
« on: December 21, 2016, 08:50 »
Well, I figured I should make a followup to apply the advice I got, so here it is. I also go on a bit about my weird AutoHotkey setup for movement, but mostly it's just straight play with commentary.

Discussion / DRL with WASD (and other simplified inputs)
« on: December 18, 2016, 02:49 »
Jupiter Hell is set to be a 4-way roguelike AFAIK due to accessibility issues with numpads missing from laptops, and generally with 8-way input. I thought about this, and experimented a bit with different input ideas, to see if there was a more accessible way to do 8-way movement without a numpad. To that end, I did a few experiments.

Experiment 1: WASDQEZC

This was my first attempt, basically just WASD with explicit diagonals strung around it. It worked about as well as could be expected: kinda clumsily. It does work, but it is difficult to fit non-movement commands around it. This ultimately only worked with ESDF(WRXV) if I wanted non-movement keys on my left hand.

Experiment 2: Infra Arcana style

The second experiment was an attempt to flatten out the keys a bit, to open up room on my left hand. shift+A and shift+D would be NW and NE respectively, while ctrl+A and ctrl+D were SW and SE. It worked better than the first experiment, but seemed to favour switching E and W with diagonals. That is, NW, NE, NW, NE or SW, SE, SW, SE were far easier to do than NW, SW, NW, SW or SE, NE, SE, NE. It's also a bit annoying to hit ctrl and a direction, though shift and direction felt fine. I was trying to do this all with one hand (so my right hand could rest on the mouse), and it's more comfortable if you use the left hand for shift/ctrl and have the right hand on the arrow keys.

Experiment 3: Pure WASD (with chording)

The last experiment involved several hours of autohotkey hackery to set up properly (that is, in a way that avoided erroneous input while ensuring inputs happened as soon as they were unambiguous and still let the pressed keys through for menu control). Basically, WASD, like a shooter. so W+A is NW, W+D is NE, A+S is SW, A+D is SE. The script has to have a brief input buffer to ensure one doesn't move cardinally when meaning to move diagonally, but I've found ~50ms is both safe and quick. Basically, if you press a key and hold it for >50ms, you move in that cardinal direction. If you press and release a key within 50ms, you also move in that cardinal direction. If you press a key, and within 50ms press another key, you move in the diagonal corresponding to the combination of keys pressed. Input continues as long as the key(s) is/are held down.

Overall, I found WASDQEZC a complete wash, but the other two experiments are interesting. Infra Arcana style has perfect reliability, but can be a bit tough on the pinky finger and felt a bit slow to me (at least when using it with WASD rather than arrow keys). Pure WASD had no reliability issues that I could find, but it is theoretically possible to have input errors if one gets sloppy. I haven't had any issues in testing (my current run got through all 3 Phobos red stages with medkits to spare, and no accidental movement), but the nature of the system does not guarantee correctness. The keybindings for the Infra Arcana style, and the keybindings and AHK program+code for WASD are both attached separately, if anyone wants to test them out. If you want to change the Pure WASD keys to something else, just edit the InputKeys table (and if those keys are alphanumeric, mirror them in the first half of the OutputKeys table to keep menu control working properly) in the AHK code, and change which keys are no-ops in the keybindings.lua.

Note that the AHK script is a bit conservative, and occasionally doesn't register inputs at all (because I don't know AHK that well, so I'm not sure how best to solve the race condition causing this issue). I think this is okay, because not acting in a roguelike is a safe option, but it may be frustrating for some. Also, if you wanted to use the arrow keys for this, it will require setting the output keys (in the KeyCheck() function) to something other than the arrow keys, and then binding the cardinal movement functions to those new keys. AHK is not great at dealing with conditional key passthrough.

UPDATE (2016/12/22): I've fixed the bugs I encountered during my recent streamed test (mostly that holding a diagonal caused a long stream of cardinal movements upon releasing the diagonal), and also cleaned up a couple of other outstanding issues. The issue with registering quick repeated inputs I mentioned earlier is gone, as is the issue regarding conditional key passthrough, though to mitigate this change causing more input accidents I increased the buffer time to 67ms, which is safer anyway. Turns out I needed key passthrough anyway for handling menus, so I figure it might as well just work as the main method, rather than having no-op functions in keybindings.lua. Ironically, this means that the current version can only handle having the input and cardinal output keys be the same, unless you aren't using alphanumeric keys as input. If this is a problem for people I'll fix it, but this is the best solution to handle both menus and COMMAND_RUNMODE, and the only downside is that these directional inputs can't manipulate the main menu.

UPDATE (2017/01/01): I've adjusted the script to not immediately press a cardinal as soon as the key is released, but instead that cardinal is buffered for a few dozen ms before being sent if nothing else has happened during the buffered period, which keeps misinputs to near-zero while maintaining a sense of fluidity. The buffer length is also configurable, as is the list of games that work with it (it's set up for DRL and ToME, though I haven't included ToME keybindings), and all configuration is in a handy block at the very top of the source.

UPDATE (2017/01/12): Download links changed to point to my Google Drive. I didn't realize people who weren't logged in couldn't even see the attached files.

UPDATE (2017/02/01): Modified the buffering system slightly. The check for releasing keys is half the buffer time for pressed keys. By default, you have 67ms to press 2 keys together to make a diagonal, and 33ms when releasing them to release both in order to avoid a unintended cardinal. Also, when pressing and releasing a single cardinal alone, it will also wait 33ms before sending the input. Testing this on an attempt at Compet-N Gold, I got no misinputs all the way to Babel (I forgot to get Dodgemaster and Cybie killed me, but the inputs all worked with me going as fast as I could in tiles mode).

Infra Arcana style keybindings
WASD keybindings and AHK script+code v4 (listed as v1 in the repo)

Spoiler: WASD keybindings (click to show/hide)

Off Topic / Re: C++ and STL. How portable is JH?
« on: December 16, 2016, 21:24 »
C# and C++ are two different beasts. However, they are also the exact two beasts I tame and ride every day at work.

Off Topic / Re: C++ and STL. How portable is JH?
« on: December 16, 2016, 17:25 »
Move semantics does deal with both cases, so the performance cost of realloc/delete moves is probably negligible at gaming scales. The issue is more the cost of memory management and destructor operations on deletion, since frequent deletion and re-insertion is fairly common in games.

Off Topic / Re: C++ and STL. How portable is JH?
« on: December 16, 2016, 13:58 »
Wow, I thought that's the way std::vector is supposed to work from the beginning. At least, the insertion part.
Thanks a lot, that's enlightening!
Wait, how did you expect vectors to work?

To clarify, on insertion, the vector first checks if free room has been allocated. If it has been, the new item is added. If not, the vector's internal array is reallocated with a larger capacity (in an implementation-dependent way), all the currently contained items are moved (rather than copied IIRC) to the newly allocated internal array, and then the new item is added to the vector.

The issue for games is more to do with deletion, rather than insertion, since deleting an item from a vector calls its destructor, and causes all items after the deleted one to be moved back, to keep the data contiguous. Given that objects in games are being deleted from containers all the time, and ordering generally doesn't matter, there's a lot of CPU time spent on operations that don't provide any value for the game.

Off Topic / Re: C++ and STL. How portable is JH?
« on: December 15, 2016, 21:05 »
My understanding of the STL issues with games is a two-fold issue: STL classes are a mess of templates and virtual functions (which tends to introduce overhead), and STL containers are generally built to just work without sweating the details (which leads to inefficiently managed memory for objects)

The first issue is, as far as I can tell, endemic to any library trying to be general-purpose, but also something compilers can deal with. I don't know how much STL implementations use constexpr (new in C++14), but I wouldn't be surprised if they were trying to get as many function calls and template instantiations folded down to minimize overhead as possible, once the compiler is through with it.

The second issue, on the other hand, is indeed a design issue with STL. For applications that deal with large chunks of relatively unchanging data, they are fine. For applications that deal with data that's constantly changing in small chunks (like games) the overhead of constantly constructing and destroying objects, as well as the overhead when classes like vector<> need to expand, leaves a lot to be desired for performance. Linked list or map structures avoid that allocation issue, but have terrible cache performance, which is huge for optimization these days. On this, I don't know of any specific efforts to clean anything up, but I am aware of some research effort into containers that allow for dynamic allocation while minimizing destruction and allocation overhead, but nothing that seems likely to make it into STL for several years. Colonies are an example of this research.

There's also the whole SG14 working group, which is all about making standard C++ better for games development.

Requests For Features / Controller Support?
« on: December 15, 2016, 18:35 »
So, I noticed, though I can't remember where exactly, in discussions about 4-way movement that controller support is planned (which is somewhat novel and a touch baffling to me, but then I ran through all 3 Dark Souls games on KB+M by choice). I'm quite curious what the intent is for this. Specifically, is the plan to do something similar to most tactical games where the left stick controls a cursor and buttons do actions, or is the idea to have the left stick control movement directly and the right stick control a cursor for shooting, or make to make extensive use of the d-pad for movement, or what?

Announcements / Re: Jupiter Hell Kickstarter is LIVE!
« on: December 13, 2016, 17:25 »
And now we wait for builds.

Announcements / Re: Jupiter Hell Kickstarter is LIVE!
« on: December 13, 2016, 16:10 »
Does Kickstarter do any kind of backerkit system, or is that $70k (and the attendant resulting features) it?

Announcements / Re: Jupiter Hell Kickstarter is LIVE!
« on: December 12, 2016, 12:37 »
Yay! The breathing can resume.

Discussion / Re: D**mRL Run video to try to promote Jupiter Hell
« on: December 12, 2016, 00:50 »
Oh, wow. That's good to know about Mancubi. Should I just radar shoot them and hope for the best, or is it possible to see them and have a step away before they see me (assuming HR2 & A-modded armour)?

Pages: [1] 2