Reason for the huge time away is a combination of the awkward moving-hosts situation, trying to get the domains to work, sorting out the DNS (which was a problem on Virgin Medias behalf), and then realising that the old host had a really dumb set up that messed up PHP variables. All of that has been fixed though.

The good news is, with this host, I can actually use my domains properly, so that means RozWorld will actually be hosted on roz.world once I sort the website out. There's a few other kinks to fix with the domain and .htaccess rules but the site itself is back up and functional as it should be.

There's a bunch of progress on RozWorld that'll I'll need to get to posting, you can see the activity on my GitHub page here. I've been working on the server and netcode stuff a bunch since it has been neglected a lot. A slightly newer direction has been taken too with the main focus on getting everything organised and in sync with the API at the centre. The only thing that needs work is the client renderer which I'll be working on and off of alongside the netcode, API, server library and dedicated server console. Plugins already work and I've made a good start on the netcode (with async UDP working a treat). More updates [SOON].

I'll be moving oddmatics to a different host later on in April since my hosting time is running out on the current one, and it's pretty limiting.

In other news, I've been working on some graphics for RozWorld. The client itself has moved to GLFW instead of OpenGLUT and the dynamic texture creation does work (FONTS, they work sort of, almost there). I have plans for the rest of the rendering stuff, I'm working on a lot of the game design itself right now. Future proofing and that.

My excuse for not posting is that it has been a busy month, it's still busy a bit, sort of, but I have "more time" now at least. Maybe if I can get in the programming zone there'll be more progress, that commit history is a sad reminder...

Maybe I'll finish FontProvider.cs sometime soon, the BuildString() function is the hold up, I know of a few ways to implement it but deciding which would turn out nicest in code is a pain. It'll no doubt be a mess first time round, it'll just have to get cleaned up later.

Not long left after stuff is supposed to be done so I genuinely need to hurry up. New Year crunch I guess. :p

Last week was a bit of a mess, but here's a change up for week 4/5 combined...

RozWorld needs some big changes, mostly, this includes moving a lot of stuff around. Most important is that the server stuff will be moved to a library thing.

Why is the server being moved to a library? The main reason is because parts of it are required for the RozWorld game client, the dedicated server mode thing, and the RozWorld Editor. I'd rather have them all link to one single library instead of a mash up of executables and stuff.

This means a lot of the networking code is being binned from the main RozWorld project, and to be honest, it needs a rewrite anyway.

Also the new netcode will be tested properly and stuff, so progress will move at a weirdly slow but not actually slow pace. I'll stick it all under the RozWorld repo anyway.

Final thing, I'm looking into sorting out some of the build stuff, automatically copying libraries blah blah blah. Basically, actually using some of the features of Visual Studio. We'll see how that goes too.

I spent the day today exploring some backups of older project tests I had laying around on my drive and I realised that not only had I got good code for reading keyboard input... I needed to come up with a good hit detection system.

Previously, the old systems I whipped up used a really simple method of checking if wherever the player wanted to move to next was inside a 'solid' area or not... and if you moved more pixels than the area was in size, you could move through 'solid' objects.

Not good! But today I came up with a good scheme, whether I could just use an existing system or not is not the point here, RozWorld is just as much a learning project as it is a serious 'make-something-good' project.

So here's the plan...

In this diagram, the player wants to move from the circle, to the star, which he shouldn't be able to do as he impacts the wall at the square. That's the scenario, but to go this in practice I have devised this:

First, we can get the gradient of the vector the player is moving at, by working with his initial point, and the point in which he wants to end up. Then we use this gradient to make two line equations either side of the wall, these are the cyan lines.

Then all the hit detection does, is check if the point the player wants to end up is past the wall, and between the two cyan lines. If he's going to that area, then he's obviously collided with the wall, and he shouldn't be allowed to make the move.

Aside from that, the move shouldn't just be cancelled, the player should be placed at the wall where the player's vector met the wall. That's as simple as equating the wall's line to the player's line and seeing what it ends up as.

...That's the supposed system in a nutshell, the only thing with it is getting it into working code... so I'm going to have to develop the idea a bit first.

Whilst getting on with that, I'll be working on finishing up the last font and then implementing a better rendering system into RozWorld. Tedious work but if it raises the framerate (which it should), then I won't be complaining once it's done. :P