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~