Goplanes
Moderator: Mask of Destiny
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
Chilly Willy wrote:Cool, thanks! I've got Tiled installed from their repo, but I wonder if I can get by on just compiling the plug-ins rather than the whole thing...
Their build system isn't flexible enough to compile plugins separately, so you need to compile the whole thing. I find it's not too much of a pain for my current needs, but it does give me a bit of a hassle to release my plugin code.
As for creating new plugins, I basically took the flame plugin and duplicated it, renaming where applicable. I used it as an example.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Just built the 0.8.1 code... yeah, it wasn't a problem at all. The compiled binary works fine. Found the Flare plugin code - there doesn't seem to be anything platform specific in the plugins, so unless your plugin code makes Windows calls, it should just be a matter of copying the new plugin directory, changing the makefile, and recompiling.djcouchycouch wrote:Actually, it's not bad at all. It's well made.Chilly Willy wrote:Well, I guess it can't be as bad as some of the things I've compiled before.
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
Chilly Willy wrote:Well, I can run it in the debugger, but there's no debug symbols. I can't find any way of compiling with debug symbols in the qmake files, or the generated makefiles.
Yeah, that's the problem I had.
Follow these instructions: http://doc.qt.nokia.com/qtcreator-2.1/c ... gines.html.
If that doesn't work, follow up with this:
- open QT Creator
- open the project
- click on "tools" in the menu, then "options"
- choose the "build & run" category on the left
- choose the "Tools Chains" tab
- clone one of "Microsoft Visual C++ Compiler (x86)" items, and it will go into the "manual" list.
- choose the item you just created
- in the "Debugger" path at the bottom of that page, browse to the cub.exe in the debugger tools. For example, my path goes to: C:\Program Files\Windows Kits\8.0\Debuggers\x86\cdb.exe
- click on OK to leave the dialog
then,
- go to the Projects category of your project (between "Debug" and "Analyze").
- choose the "Build" button/tab thing
- In the "General" section, look for the "Tool chain" drop down box.
- choose the "Clone of Microsoft Visual C++ Compiler (x86)" that you created.
That should be it.
I can't find the original page that explained all that. Hopefully my instructions will be sufficient.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
That sets the debugger for QT Creator - I need to known how to turn on debugging symbols IN THE PROJECT. It's got to be some kind of build option... not that I can find one. Somehow, when qmake runs, it adds -DQT_NO_DEBUG to all generated makefiles.
EDIT: Figured it out... you need to add "CONFIG += qt debug" to tiled.pri in the root directory.
EDIT: Figured it out... you need to add "CONFIG += qt debug" to tiled.pri in the root directory.
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
That's strange. I didn't have to do that and I can debug it. Hmmm.Chilly Willy wrote:That sets the debugger for QT Creator - I need to known how to turn on debugging symbols IN THE PROJECT. It's got to be some kind of build option... not that I can find one. Somehow, when qmake runs, it adds -DQT_NO_DEBUG to all generated makefiles.
EDIT: Figured it out... you need to add "CONFIG += qt debug" to tiled.pri in the root directory.
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
Update!
Goplanes Dev Video 015
http://youtu.be/tjb5SRYFVUA
Description:
Yep, still working on it!
The brand new feature in this version is weapon power ups. Still have no idea what kind of weapons (or weapon system) the game will have, but I thought adding a fireball gun would be fun to do. If you get hit, you lose the item, but you can pick it up again.
Other than that, lots of tweaks.
- Changed the health bar to have more health points. Actually reduced the number of sprites used to indicate health (two 8x32 sprites now vs. three 16x16 sprites before)
- Wall bounces (but not sky edge bounces) now cause damage, just like the original Goplanes. Hopefully the added difficulty will be offset by the increased number of health points. For sure there will be health pick ups at some later time.
- Realized that the flying rotation lookup tables had slightly skewed values. Now when flying in a circle, the plane doesn't drift towards the upper left anymore.
- I was computing object visibility in too many places, now I compute it once during object update, cache the result and check it instead of calling the visibility function everywhere. Simple optimization.
- Fixed the radar arrows so that they don't move when the scrolling has reached a screen edge. It was distracting.
- The map exporter for Tiled also exports horizontal and vertical flipping. The two green blocks at the bottom of the screen show this off.
In other news, collision code is too damn slow. I'm limiting collisions to certain types and only when they're visible on screen, but firing six to eight bullets with a half dozen collidable objects slows the game down to 30 fps. I think the level design will naturally limit the number of active objects visible, but it bothers me that it's not faster. I haven't been able to come up with a solution to speed it up. Not even the Bresenham circle algorithm can help!(*)
(*) totally an inside joke. Hi Fred!
Goplanes Dev Video 015
http://youtu.be/tjb5SRYFVUA
Description:
Yep, still working on it!
The brand new feature in this version is weapon power ups. Still have no idea what kind of weapons (or weapon system) the game will have, but I thought adding a fireball gun would be fun to do. If you get hit, you lose the item, but you can pick it up again.
Other than that, lots of tweaks.
- Changed the health bar to have more health points. Actually reduced the number of sprites used to indicate health (two 8x32 sprites now vs. three 16x16 sprites before)
- Wall bounces (but not sky edge bounces) now cause damage, just like the original Goplanes. Hopefully the added difficulty will be offset by the increased number of health points. For sure there will be health pick ups at some later time.
- Realized that the flying rotation lookup tables had slightly skewed values. Now when flying in a circle, the plane doesn't drift towards the upper left anymore.
- I was computing object visibility in too many places, now I compute it once during object update, cache the result and check it instead of calling the visibility function everywhere. Simple optimization.
- Fixed the radar arrows so that they don't move when the scrolling has reached a screen edge. It was distracting.
- The map exporter for Tiled also exports horizontal and vertical flipping. The two green blocks at the bottom of the screen show this off.
In other news, collision code is too damn slow. I'm limiting collisions to certain types and only when they're visible on screen, but firing six to eight bullets with a half dozen collidable objects slows the game down to 30 fps. I think the level design will naturally limit the number of active objects visible, but it bothers me that it's not faster. I haven't been able to come up with a solution to speed it up. Not even the Bresenham circle algorithm can help!(*)
(*) totally an inside joke. Hi Fred!
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
I created the project by importing an existing project and editing the build step to add a qmake step before the make step. But with an imported project, there are no separate debug or release versions, there's just the project, period. Maybe if I had separate debug/release versions, it would automatically include the flag. Just not sure how to do that for an imported project.djcouchycouch wrote:That's strange. I didn't have to do that and I can debug it. Hmmm.Chilly Willy wrote:That sets the debugger for QT Creator - I need to known how to turn on debugging symbols IN THE PROJECT. It's got to be some kind of build option... not that I can find one. Somehow, when qmake runs, it adds -DQT_NO_DEBUG to all generated makefiles.
EDIT: Figured it out... you need to add "CONFIG += qt debug" to tiled.pri in the root directory.
Anywho, I did get it to build and debug with symbols and all, so I can run it in the debugger with source.
I like the latest video... the radar arrows pointing to the bad guys is pretty cool.
As to collision detection, that's why some games are more sloppy that others... to speed up collision detection. Have you tried a simple bounding box? Not very accurate, but DAMN FAST! Combine that with a table of what is in every 16x16 block in the map (ORd as bits) and you should be able to check tons of stuff each frame.
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
Are you opening the project directly into QT Creator or using the QT Creator plugin in Visual Studio? Also, are you running it on Windows?I created the project by importing an existing project and editing the build step to add a qmake step before the make step. But with an imported project, there are no separate debug or release versions, there's just the project, period. Maybe if I had separate debug/release versions, it would automatically include the flag. Just not sure how to do that for an imported project.
Anywho, I did get it to build and debug with symbols and all, so I can run it in the debugger with source.
I am indeed using bounding boxes for collision detection between two objects. What else could I be using?As to collision detection, that's why some games are more sloppy that others... to speed up collision detection. Have you tried a simple bounding box? Not very accurate, but DAMN FAST!
I tried to think about a solution using that idea, but nothing I'm happy with. Concerns are:Combine that with a table of what is in every 16x16 block in the map (ORd as bits) and you should be able to check tons of stuff each frame.
- For any random sprite, it could cover multiple 16x16 blocks. I'd have to update up to four 16x16 blocks for a 8x8 sprite and up to nine 16x16 blocks for a 32x32 sprite. I'm not sure if that would wind up to be less computation that my current scene.
- I would need to somehow distinguish between different object types because not every object collides with every other object. And objects react differently to different objects.
But I'm still rolling the idea in my mind.
I took another look at the collision code.
This is how I've been testing collision between two objects. *tempFirstList and *tempSection are instances of ObjectStruct, the structure used to represent game objects. "collisionFunction" is a function pointer. It can either point to SquareSquareCollision() or PointSquareCollision().
Code: Select all
if (collisionFunction(*tempFirstList, *tempSecondList))
{
(*tempFirstList)->collisionFunction(*tempFirstList, *tempSecondList);
(*tempSecondList)->collisionFunction(*tempSecondList, *tempFirstList);
}
All my collision tests use SquareSquareCollision(), so I took a look at it.
Code: Select all
u16 SquareSquareCollision(ObjectStruct* firstObject, ObjectStruct* secondObject)
{
if (firstObject->x + firstObject->rectLeft > secondObject->x + secondObject->rectRight) return 0;
if (firstObject->x + firstObject->rectRight < secondObject->x + secondObject->rectLeft) return 0;
if (firstObject->y + firstObject->rectTop > secondObject->y + secondObject->rectBottom) return 0;
if (firstObject->y + firstObject->rectBottom < secondObject->y + secondObject->rectTop) return 0;
return 1;
}
So I took out the function pointer call since all my collisions are square-square anyway, and replaced it with an if statement. Looks like this now:
Code: Select all
if (!((*tempFirstList)->x + (*tempFirstList)->rectLeft > (*tempSecondList)->x + (*tempSecondList)->rectRight ||
(*tempFirstList)->x + (*tempFirstList)->rectRight < (*tempSecondList)->x + (*tempSecondList)->rectLeft ||
(*tempFirstList)->y + (*tempFirstList)->rectTop > (*tempSecondList)->y + (*tempSecondList)->rectBottom ||
(*tempFirstList)->y + (*tempFirstList)->rectBottom < (*tempSecondList)->y + (*tempSecondList)->rectTop))
{
(*tempFirstList)->collisionFunction(*tempFirstList, *tempSecondList);
(*tempSecondList)->collisionFunction(*tempSecondList, *tempFirstList);
}
There are many places where the game code is written to be architecturally straightforward and understandable rather than for performance. So, logically, there are lots of functions and function calls. I'm certain that I'll eventually find many similar optimizations to the one above.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
Goplanes Dev Video 016
http://youtu.be/9zuKr1L7BFc
From the description:
The game now supports having a level split into smaller sections and being able to go from section to section through "doors".
Sections are small because it's a quick test. They can be much larger than what is in the video.
Was scared I wasn't going to have this finished this week as this, while very important, was pretty boring work Had to refactor the game loop again which is always fun.
Anyway, every section can have up to four doors which is a totally arbitrary limit. Doors can be placed anywhere and can be any size.
After dying, the player comes from the last door they flew through. This works ok for now, but I might have to handle this better through checkpoints. Having the player come through the last door they took might have them fly smack into a difficult area over and over again.
I haven't figured out a good way to indicate to the player which edge of a level is a door and which is not. At the moment, there's no way to tell if there's a door. Flags flapping in the wind? Arrows? a different color sky? Not happy with any of those ideas.
Obvious bugs are enemies get respawned whenever the player reenters a section. That'll be handled better. Destroyed enemies will be kept destroyed.
http://youtu.be/9zuKr1L7BFc
From the description:
The game now supports having a level split into smaller sections and being able to go from section to section through "doors".
Sections are small because it's a quick test. They can be much larger than what is in the video.
Was scared I wasn't going to have this finished this week as this, while very important, was pretty boring work Had to refactor the game loop again which is always fun.
Anyway, every section can have up to four doors which is a totally arbitrary limit. Doors can be placed anywhere and can be any size.
After dying, the player comes from the last door they flew through. This works ok for now, but I might have to handle this better through checkpoints. Having the player come through the last door they took might have them fly smack into a difficult area over and over again.
I haven't figured out a good way to indicate to the player which edge of a level is a door and which is not. At the moment, there's no way to tell if there's a door. Flags flapping in the wind? Arrows? a different color sky? Not happy with any of those ideas.
Obvious bugs are enemies get respawned whenever the player reenters a section. That'll be handled better. Destroyed enemies will be kept destroyed.