2013/11/19

Developer Shame

Figures. I add a countdown clock, and then proceed to totally miss every single deadline.

I must admit the lack of updates has been more of a shame-based vicious circle than anything else.

Essentially, I felt ashamed for not having a project update ready, and decided to keep pushing forward, but felt ashamed for not having posted blog updates, and thus would not update the blog until I had a software update...

In any case, beyond real-life issues that no one reading this really cares about, the major problem has been technical issues with the Java libraries. As follows...




The first issue, and many Java developers will have flashbacks now, was with the Keyboard input listener under Linux.

For those no in-the-know, upon pressing a key, the OS (Operating System) will trigger a "Key Down" event, which indicates the specific key being pushed so programs can register and handle it as they like. Once the key is released, a "Key Up" event is triggered.

These events are vital for things such as having your character move around for as long as a key is held down, and stop moving as soon as it is released.

Under Linux, there's a catch: Upon a key being pressed, the OS will immediately send a "Key Up" event, and then continue sending "Key Down" and "Key Up" events for the key being held. From what I've gathered, this is to enable key repeating under the terminal environment, and can be configured at the System level. Unfortunately, a major point of Java development is platform independence, so I can't just ask users to configure their system for my game (not as long as there are alternatives).

The solution, in the end, was to take control of the input event queue, peek at the next event in queue, and if said event was a "Key Up" event with the exact same timestamp as the previous "Key Down" event (That is, was sent at exactly the same time), it would be ignored. It works, sort of.


The second issue has to do with the way I implement windows, and is somewhat compounded by the solution to the previous issue.

The thing is that, when switching to fullscreen, the window would lose the input event queue, and thus stop responding to user input, although not always.

Fixing this meant reworking how the input listeners are connected to the window contexts, which was somewhat complex. I won't get into details, let's just say I had made many design mistakes that I'm paying for now. But that's how software design works, anyway.


Then came the third issue... Which I will call the "Irony Issue" from now on.

What happened is that I went ahead with the implementation of gamepad support, using the Jinput library, and found out that the way the library implements input controls isn't compatible with my current implementation.

Yes, this means that after all that work to fix those issues, I still need to rewrite the whole thing.

Currently I'm trying to use Jinput for mouse and keyboard input too, which might, hopefully, solve the first issue. It might also help with another pesky issue, namely that I can't read more than two keypresses at once, which could derail the whole project if not solved. We'll see.


Oh, right, there's a final issue... But I'll talk about that on another post...

Update: No, I won't. I had half-decided to ditch the DooM theme and go for my own content... But the very reason I chose to make a DooM fangame in the very first place reared its ugly head: I began getting lost in the design of said content, and losing focus on developing the engine. So back on track for now.

No comments:

Post a Comment