login | register

New game

New game
16th Feb 2010 - 07:55	by sneeze
So, I've had an idea for extending Qilox a little and making something a bit more unique (although not very unique, if you can have degrees of uniqueness). Unfortunately, it appears that my original engine for Qilox is hopelessly inadequate for the job. The problem is that Qilox works entirely on bitmaps. It draws on them, uses the flood fill function to check areas captured etc etc. State of the game is held entirely on a bitmap. This is perfectly fine... for a game where the lines are only vertical or horizontal, and where the enemies only travel in diagonals. Divide and Conquer has a system allowing lines that are not vertical or horizontal. This means that firstly they need antialiasing or they look awful, and secondly that bouncing an enemy off a line becomes nontrivial, especially if I potentially lose the information about the start and end of line when I draw it. Ultimately, bitmaps are not adquate for this job. Hence I need an entirely new engine. Various Real Life (tm) issues have cropped up (to do with house hunting, mainly) which have made it a bit harder to get on with stuff since last thursday, but I've made some progress in basing a game around vector graphics. What I need to do today is remember how to check if a line crosses another line, work out where they cross, then do a bit of reflection if they do cross. Once that's done, putting the game together shouldn't be -too- hard... I hope! As an aside, I've been practising my drawing a little more lately. I've been trying to work out how to get Sheep to do a few more interesting things, as well as working on my real life drawing. Much of it is pretty rubbish, but I think my cartoon sketching is getting a little more confident at the very least!

Replies: |1-10|

17th Feb 2010 - 13:52	by jansic
Divide and Conquer has a system allowing lines that are not vertical or horizontal. This means that firstly they need antialiasing or they look awful, and secondly that bouncing an enemy off a line becomes nontrivial, especially if I potentially lose the information about the start and end of line when I draw it. Ultimately, bitmaps are not adquate for this job. Aha, you've finally had to step over the snowflake line :) If you want, there's some old code in the cataclysm project (in CVS) to do things like this (although it's mainly circle based), the relevant functions are in 'engine/Environment.cpp' As personal preference I tend to pass lines around as start,delta rather than start,end because the values match the maths better. Stick with 2D Vector maths too - solving equations the standard way can leave you with a lot of mathematical corner cases to handle...

18th Feb 2010 - 12:22	by sneeze
So, I notice this -after- I've written at least adequate routines for all this ;) To be honest, though, it's quite hard to reuse other people's code though for this sort of thing, at least not before you know how you want to do it. Will probably have a look anyway though :) At the moment, I've got the wonders of issues with corners though and the inevitable rounding errors.

18th Feb 2010 - 14:40	by jansic
At the moment, I've got the wonders of issues with corners though and the inevitable rounding errors. With point-objects this should be a non-issue but if your objects have size, your collision routines must either be capable of returning multiple results or return the most important result from multiple intersections. The most crude solution for non-point objects is to allow penetration, measure the largest penetration and use that to back up the simulation then apply the response. It's not correct but that needs things like surface normal coalescing and all sorts of overly involved maths.