Monday, March 29, 2010
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).
Monday, January 18, 2010
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~
Friday, October 23, 2009
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~
Azriel~
Tuesday, September 22, 2009
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~
Friday, September 18, 2009
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~
Friday, September 4, 2009
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
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~
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~
Monday, August 31, 2009
[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.
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.
Subscribe to:
Posts (Atom)
