A brand new game
for Windows, HTML5, iPhone, Android TV and more,
After a day spent trying to track down the issue(s), I've finally got WinSock to return exactly what I expect it to return!
I can't rest yet, as I need to foolproof the values being returned, and also then get it working on things other than Windows...
WinSock is strictly for Windows, so .. It's going to be a system-by-system rewrite to get everything on the same level.
But I'm about 50% confident that I'm able to send requests from the Windows editions of the games.
*sigh* That took a while!!
I finally dug my heels into the Net code, last night.
For the meantime, it'll be very Windows specific, and I'll have to tackle each different system in it's own way.
Something isn't right.
A curious dilemma.
My internet code is broken.
Some sort of error.
Logging into the Mac, I copied the AGameAWeek Framework folders over, and tried to run a lengthy scrambled mass of "Terminal" (stop calling it Command Prompt, Jay!) commands in order to get it compiling.
After about an hour or so of tweaking the command, I got the thing outputting GLFW errors, which is an improvement from what I started with!
Booting up the Mini Mac,
To try to run my game.
I'm going to have to tweak a bit,
Before it runs again.
My controllers aren't working in Linux.
There's something awry in my code.
Or maybe it's just in the VirtualBox,
Upon which the Ubuntu doth load.
OK, the mouse stuff seems to be working with overscan, now, which is good.
Additionally, the Game Controller code appears to be kinda ok.
I've set up the engine/framework/etc to assume all controllers are "The player's input", so I'm going to be doing 1-player only stuff until I can be bothered to faff about with it some more and implement multiplayer controller code!
Unfortunately, I don't 100% trust what GLFW3 is telling me.
The controller input list here is suggesting that DPad Up is "button #11", whilst my X360 pad is returning true for "button #10" whenever DPad Up is pressed.
I'll have to try a variety of controllers, I think, and try to figure out how best to handle the different types.
Worryingly, it might even be Win10, or the driver code, which is giving the incorrect result.
Mouse, and of course, touchscreen.
They both took a bit of a tumble, last night.
The overscan seemed to be working, but I was only testing it with controllers, since the overscan is typically only used on Android TV versions of the games.
Yesterday, however, I chose to reuse the overscan functions on iOS.
My mouse co-ords have all messed up,
Since adding overscan.
I'll have to fix them up again,
The best way that I can.
<- 4:3 | iPhone ->
The menu seems to be scaling fairly well, which is nice.
Poor single-pixel Platdude outline looks a bit gnatty, but that's "GL_Nearest" sprite scaling for you :\
I'm confident that, once on an actual device, the resolution increase will help to fix that.
Either way, the screen seems to fit all my test screen resolutions well enough to move ahead with the next task.
I must've spent about 5 hours, yesterday, trying to find the right sound for a new AGameAWeek Jingle.
Getting sidetracked by a minor thing,
Which takes up all your time.
Hours you spend, to make it right.
Until it turns out fine.