Goplanes

Announce (tech) demos or games releases

Moderator: Mask of Destiny

Post Reply
Chilly Willy
Very interested
Posts: 2809
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Jun 10, 2012 5:35 pm

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...

djcouchycouch
Very interested
Posts: 683
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Mon Jun 11, 2012 2:47 pm

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.

Chilly Willy
Very interested
Posts: 2809
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jun 11, 2012 4:07 pm

Well, I guess it can't be as bad as some of the things I've compiled before. :lol:

djcouchycouch
Very interested
Posts: 683
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Mon Jun 11, 2012 4:10 pm

Chilly Willy wrote:Well, I guess it can't be as bad as some of the things I've compiled before. :lol:
Actually, it's not bad at all. It's well made.

Chilly Willy
Very interested
Posts: 2809
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jun 11, 2012 5:52 pm

djcouchycouch wrote:
Chilly Willy wrote:Well, I guess it can't be as bad as some of the things I've compiled before. :lol:
Actually, it's not bad at all. It's well made.
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
Very interested
Posts: 683
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Mon Jun 11, 2012 5:54 pm

Check to see if you can debug it. For me, it wouldn't work out of the box. I had to install the Debug Tools for Windows and change a project setting that I forget. I can't get to at the moment as I'm at work.

Chilly Willy
Very interested
Posts: 2809
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Jun 12, 2012 7:33 am

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. :?

djcouchycouch
Very interested
Posts: 683
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Tue Jun 12, 2012 10:53 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.

Chilly Willy
Very interested
Posts: 2809
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Jun 12, 2012 6:30 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.

djcouchycouch
Very interested
Posts: 683
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Sun Jun 17, 2012 12:34 am

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.
That's strange. I didn't have to do that and I can debug it. Hmmm.

djcouchycouch
Very interested
Posts: 683
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Sun Jun 17, 2012 12:35 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!

Chilly Willy
Very interested
Posts: 2809
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Jun 17, 2012 2:21 am

djcouchycouch wrote:
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.
That's strange. I didn't have to do that and I can debug it. Hmmm.
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 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.

djcouchycouch
Very interested
Posts: 683
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Sun Jun 17, 2012 7:00 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.

Anywho, I did get it to build and debug with symbols and all, so I can run it in the debugger with source.
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?
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 am indeed using bounding boxes for collision detection between two objects. What else could I be using? :)
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.
I tried to think about a solution using that idea, but nothing I'm happy with. Concerns are:
- 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);
}
Right there, I figured that the function call with parameters is probably expensive.

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;
}
Super ugly, right? Why perform four if statements? Why not just return the boolean result? That obviously can be written better.

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);
}
So now, running the same scene as before, the framerate drops to only 55 instead of 30 which is a pretty good improvement for a simple change. So I'm not so worried about it now.

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.

Chilly Willy
Very interested
Posts: 2809
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jun 18, 2012 5:56 am

I'm opening it directly in QT Creator in linux.

Your collision speed is probably now directly related to how you process the lists. List processing is a big area for optimization in many programs.

djcouchycouch
Very interested
Posts: 683
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Tue Jun 26, 2012 1:40 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.

Post Reply