Free From Memory

Another check in, the past few months I set off to remove all memory leaks from hero quest, using Valgrind (or more specifically, mem-check). However, I encountered this:

"At one end of the scale, Memcheck adds code to check every memory access and every value computed, making it run 10-50 times slower than natively."

One of the memory intensive things with most games is loading images or textures. As the character selection screen loaded the same images multiple times, whenever I was trying to free memory around there, I had to wait approximately 5 seconds for the screen to load. If you choose "VS Mode" in any computer game, you expect it to load the character selection screen instantly; 5 seconds is a long time.

This prompted me to add a caching layer on top of my image loading. However, my coding skills at the time of writing the graphics component were not at a level that enabled me to produce extensible code. So, I spent a few months doing the following:

• Replacing SDL 1.2 with SDL 2.0 (SDL 2.0 was released)
• Rewriting the graphics component from scratch
• Updating existing code to use the rewritten graphics component
• Finding memory leaks, and fixing them (if possible*)

* some leaks were detected in SDL and system libraries, I did not fix these

I'm happy to say the final result of this is the following Valgrind report:

==4498==
==4498== HEAP SUMMARY:
==4498==     in use at exit: 56,314 bytes in 469 blocks
==4498==   total heap usage: 129,540 allocs, 129,071 frees, 519,910,160 bytes allocated
==4498==
==4498== LEAK SUMMARY:
==4498==    definitely lost: 0 bytes in 0 blocks
==4498==    indirectly lost: 0 bytes in 0 blocks
==4498==      possibly lost: 0 bytes in 0 blocks
==4498==    still reachable: 55,998 bytes in 460 blocks
==4498==         suppressed: 316 bytes in 9 blocks
==4498== Reachable blocks (those to which a pointer was found) are not shown.
==4498== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==4498==
==4498== For counts of detected and suppressed errors, rerun with: -v
==4498== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 6)

What's next:

• Launching a game instance with selected characters (including assigning an ai controller)
• Maps / backgrounds
• Interaction between characters

Awaken!

Been a while since I've posted, but Hero Quest went through another rewrite (I know =/). Here's where I've gotten up to since the rewrite:

That's running on Ubuntu - g++ on windows did not yet have support for atomic_int when I attempted to compile Hero Quest there; haven't re-attempted to compile on Windows yet.

Syntax for character data has changed to using xml, and hopefully it's going to make things easier. Check out heat.xml.

The app is also theme-able, and the widget animations scriptable: theme.xml.

My next major step is to get a control settings menu done, some refactoring, and then I'll start working on the parts needed for gameplay. Main reason is to get the "boring bits" out of the way first. Fun stuff will be fun.



Azriel~

One More Menu

What's new? Well, I've adopted c++11, or at least, started to.  The GNU Compiler Collection doesn't yet have support for std::thread on Windows as far as I could tell, will be great when that's done.

For visible changes though, I've started work on the character selection menu (yay!).  Getting the logic done now, but for the actual design and how it will look in the end, that's something that will be done later. Here's a screenshot that doesn't look very exciting:

What it can do now is cycle through available characters and change teams (the border around the face pic changes colour).  I really enjoy working on this, but I might not be able to speed up progress just yet (will try though). Until next time.



Azriel~

One year later

And no I haven't given up yet.  I have been busy, and with university over, and work started, I still have managed to do a little work on hq:

Interesting things in that screenshot:

• Life bars (they change colour the lower the character's hp is)
• Shadows

I don't really want the life bars to stick under characters while fighting, seems a bit distracting, although it helps identify the weakest target.  Probably will go with a user interface overlay.

For shadows, the direction the light comes from can be changed (left to right angle, and top to bottom angle), but currently the shadows are just rendered flat onto the ground.  I've been reading up on shadow mapping and perhaps I'll implement it in the future, but if I don't, then we might just revert to simple shadows.

Right now I'll be working on the user interface, and then on more of the in-game logic (catching is buggy). Oh and, characters can be killed now (the logic for how to deal with a "dead" character is harder than you'd imagine).

Azriel~

Floating rocks... what next?

Work ended, university started, and I didn't feel like doing assignments, so, I took some time to work on the platforms for Hero Quest. I think it looks pretty shiny now, with the Storm Cliff map graphics drawn by Blue Phoenix. Not tested thoroughly, and certainly not bug-free. Anyways, I won't be working on HQ for another while while assignments keep coming. Till next time.



Azriel~

Slowing down

Work starts on Monday (first day at a real software company, yay), but that means progress on hq will be slowed.  Anyway, things I've done since the last update:

• background animation
• parallax scrolling (includes acceleration/deceleration)
• parsing character attributes (walking frame rate, speed, etc.)
• linking character attributes with the processor
• linking map friction with object behavior
• object points for maps (creating objects at the start of a game)
• correcting data parsing (various bugs)
• pulled out the frame element parsing from the Frames class into a common parser so that the code can be reused (instead of duplicating the object point code into the Map class, a single call to the corresponding function can provide the same functionality)

Also, here's a video of the camera scrolling + background animation:



I plan to get platforms working next, but still thinking about the design (the last one had to perform operations on platforms in multiple places, going to see if that can be reduced and contained).



Azriel~

Maps

Exams over - time for an update. Cleaned up the loading code so it's easier to add objects to the game without having to recompile, and also wrote code for maps - analogous to backgrounds in Little Fighter 2.  However, maps will be more interactive and dynamic.

The syntax differs slightly from the LF2 background data files - filled rectangular areas now use rgba values to specify the colour, and pngs are able to be used for the images. The transparency tag hasn't been implemented, as you may use pngs if you want to have transparent areas in a layer

TODO list for maps:

• parallax scrolling (with camera)
• animation
• layers that render over characters
• linking map data with objects (bounds, friction, etc.)

Other things to do in the near future are opoints and interaction.  That's all for tonight.

Azriel~

Loading...

Spent some time writing the code to load externally configurable file that determines the objects that are loaded into the game.  Works if you don't have any blank lines, but otherwise the app crashes.  Next update will be after exams (if work doesn't start so soon).  Anyways, this next term's workload + exams will be ×1000 stressful. not so fun.



Azriel~

Massive update

Been a while since I posted, I've ported approximately half of what's done in the Java version into c++, and I've got it set up to use either SDL or OpenGL for rendering. Above is a benchmark test when using OpenGL. The SDL version started slowing down at around 600 objects on screen (slower but gradually decreasing frame rate), while the OpenGL version could handle >5000 objects without lagging. Above 5000, you still get 30 fps, but keystrokes can be lost, and sometimes the animation jerks (stops for ~2 seconds, then restarts).

Anyway, next thing I'm gonna code are other objects, then collision detection.

Azriel~

Translating

Been translating the sourcecode from Java to c++, so far the data part has nearly been done (save for special effects). Haven't properly tested it (for both functionality and memory leaks (no more automatic memory management =z)). Been doing optimizations with the code as well, working with the data as a character array instead of as a string object (for the most part).

Anyways, we've started on openGL in uni, so might work on that in the upcoming holidays, depending on how quickly I manage to finish assignments.

Azriel~

not over yet

ya, haven't been working on hq, but I've been busy with uni work + summer school. Still haven't implemented the Java3D libraries.

Side note, I'll be taking an OpenGL course in uni maybe this year, maybe next, so there's a chance that I'll be porting this to c++.

Azriel~

Checking in

Haven't been updating, and that's due to heaps of assignments @ uni. I'll restart working on HQ on the 16th, where I'll be trying to link this with Java3D (for performance gains).



Azriel~

Slow motion enabled

I've finally implemented slow-motion with more or less no bugs (at least, I have only encountered one so far which I haven't had time to fix.

Updates:
- Time slow
- Special effects can be set for every object on the field excluding the caster, or for all objects not on the same team
- Objects inherit their opointer's frame speed and degree of time-stop

Bug fixes:
- Floating chars did not work well after the previous re-ordering of the frame processing sequence. This has been fixed

Bugs found:
- Characters can float (watch julian in the video) if they return to the airborne frame just as they are landing.
- Flying characters float all the way to the screen in slow-motion

Next update won't contain "new" features. I'll be focusing on fixing what I already have.



Azriel~

Special effects - timestop

Added "special:" tag to implement special in game effects
special: 1 enables one degree of timestop to all Actors
special: -1 disables timestop

Been quite busy with uni work, and gameplay isn't my main focus ftm - gotta get the UI remade properly.



Azriel~

Little update

Nothing to show here, but I fixed the platform "teleporting" bug by including a special fixed bdy into each object. This way, even if with user defined bdys in each frame with different coordinates/dimensions, the platform/wall detection will use the fixed bdy's area (extends equally in both x/z axes, fixed single extension in the y axis). The fixed bdy can be denoted in the using the tag

bound: x [y [z]]

(i.e. an argument tag that takes 1, 2 or 3 arguments). If you leave this tag out, the program will use preset values. However, I still have to fix this bug for cpoints and wpoints (opoints as well?).

Another thing I've started working on is a better code structure for the main program. The version in the last release was rather messy (all "sections" of the menu were closely coupled). I've split each menu into a different class, and written the code so that future changes would be easier (keep reading). With the new structure, it will be easier for users to write their own themes/skins, and possibly write their own user interfaces in the future. In the next post I will give a preview of the new UI.



Azriel~

[Release] 31st August 2009

Download

Hero Quest - 31st August 2009
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Characters:
- Aeron (YinYin/Havoc Creator), slightly modded by Azriel (flight)
- Joe (Siegvar)

Backgrounds:
- Lion Forest (Marti), edited by Azriel (vertical scroll, castle)


Notes:
~~~~~~
More of a feature preview than a "playable" release, you can write your own code to test stuff, but a rundown of some of the differences between HQ's data files and LF2's data files:

x new tags
Backgrounds:
- [friction] fx: 1.25 fz: 1.25
- [ybound] y1: -600 y2: 0
- [opoints] check bg/sys/lf/bg.dat

Characters:
- [hold_<a,j,d>]
As long as you're holding A, J or D, your character will go to the frame number specified in hold_a: # (for example) after the wait: # is up. i.e. This serves as an alternative next: # frame. hit_a: will have priority over hold_a: (if you press A on a frame with both tags enabled)

- [z coordinate areas]
z1: z2: are used for bdys and itrs. This is an alternative to the zwidth: tag whereby z1 == -z2 if used. If none of these tags are specified, the data will treat it as LF2 does - z1: -12 z2: 12.

- [z axis opoint]
In LF2, objects spawned via opoint are always Parent.z + 1. With the z: tag, you may opoint relative to the Parent's z coordinate. Using z: -1 will cause the spawned object to have the same z-axis coordinate as the Parent.

*Parent here means the object with the opoint:


---------------------------------------------------------------------

The castle object is made from a few different "objects" (single data file, different frames). This is to give the impression of a "room" with different z-levels. If you try and get on top of the castle via the stairs, you'd notice that your character tends to "teleport" to different places. This wouldn't happen if there is only a single identical bdy used for all of the frames, which would be much easier to work with for wall/platform detection. However, bdys keep varying in each frame, so to not have it buggy is near impossible.

Don't kill yourself trying to get onto the castle with Joe, it takes quite a number of tries.

charging/continuous inputs enabled

New tags have been implemented: hold_a: hold_j: and hold_d:
Basically they're the same as hit_a: hit_j: and hit_d:, but it doesn't care how long ago you pressed the keys, as long as you are holding it on the frame. also, it doesn't just "skip" to the frame, it waits for the wait: value to be up, and then goes (as in, it's the same as just having the hold_x: frame # as the next: #).

In the video, when you do D (forward) A with firen, you do the normal fireballs. however, if you do D (forward) A and hold A, it will shoot the big fireballs. Also, when you do DVJ, it just does a single flame; if you hold J continuously, he will keep breathing fire.

Azriel~

Small updates

Tested out Aeron on Hero Quest today. Exposed a number of bugs, some of which I fixed. Messed about with 2 players flying around. It was cool:



updates:

• improved code structure and condition checking for interactions
  


• added loading for light weapons and heavy weapons
  


• added rebound functionality for energy blasts


• set dv[x|y|z] 550 to stop Actors from moving


• implemented state: 100 (next: to frame 94 when you land on ground)


• enabled z axis movement for dvz: in the frame header

bug fixes:

• fixed data loading for extra unused tokens (e.g. wait: 10 6)

Azriel~

Platforms, camera, opoints

Updates:

• Camera scrolling works perfectly (y/z axis scroll may need correction of coordinates)
  
• Platforms (buggy)
  
• Multiple opoints
• z coordinate opointing

Azriel~

Camera scrolling - extended

adding on to the camera scrolling, there's y and z axis scrolling now (both planes taken into account, shown in video by jumping up while on different z coordinates).

layer scrolling half works, I've got the algorithm slightly wrong (that's why you see the black bars on the right). Gotta fix those in the next update.



Azriel~