Qhimm.com Forums
Project forums => Q-Gears => Topic started by: Akari on 2006-09-28 15:44:51
-
New update in svn.
2006/09/27
- [ffvii] Fix error with wrong parameter in WSPCL opcode. [Akari]
- [ffvii] Fix error with string reading in OpcodesToRawScript. [Akari]
* [ffvii] Add message typing. [Akari]
v0.04c
2006/09/27
+ [ffvii] Change version number to v0.04c. [Akari]
- [ffvii] Fix script reading function tries to write u32 to u8 value. [Akari]
- [ffvii] Fix small errors in new windowing system (input). [Akari]
2006/09/26
+ [ffvii] Rework windowing system. Windows are now more important than Messages (they are part of windows now). [Akari]
* [ffvii] Add memory bank access to WNUMB. [Akari]
* [ffvii] Fix some errors in PLUS and MINUS opcodes. [Akari]
2006/09/19
* [ffvii] Add STTIM (0x38) field opcodes support. [Akari]
* [ffvii] Add WNUMB (0x37) field opcodes support (without memory bank access). [Akari]
* [ffvii] Add WSPCL (0x36) field opcodes support. [Akari]
* [ffvii] Implement special window support in WindowManager. [Akari]
2006/09/15
- [ffvii] Fix scripts and dialogs was not cleared when load new map from XML. [Akari]
- [ffvii] Fix all scripts that stored in priority slots were run, not only highest one. [Akari]
+ [ffvii] Change script handling to real game like. [Akari]
2006/09/14
- [ffvii] Fix transparent window didn't display transparency on units and walkmesh. [Akari]
- [ffvii] Fix script calling when script doesn't exist. Add sanity check. [Akari]
* [ffvii] Implement basic xml support. May load Dialog and Entity from XML. [Akari]
And I upload compiled version with resources to my own site.
http://jrpg.ru/qgears_ffvii.zip
-
Add few changes:
2006/09/29
* [ffvii] Add WREST (0x53) field opcodes support. [Akari]
+ [ffvii] Moved window initialisation to reset method. [Akari]
* [ffvii] Add SET-BYTE! (0x80) field opcodes support. [Akari]
* [ffvii] Timer now count down automaticly as you show it and stop as soon as you close this window. [Akari]
+ [ffvii] Make Gamestate and Database non constant wher returned from their get methods so anyone can change it. [Akari]
+ [ffvii] Rewrite Field managers. Now FieldModule contains MemoryBank instead of Script. [Akari]
New version of windows binaries are at http://jrpg.ru/qgears_ffvii.zip
-
impressive.
Althought the field module seems to end up locked on one perticular scene with a timer counting down. You cannot quit or use any of the keys to move around the field view.
-
You cannot quit or use any of the keys to move around the field view.
This features are not implemented yet :wink:
-
Ah, ok. Just those keys are displayed on the screen, thats why I thought they might work...
-
Mmm they were =)
Just small error with window class. Already fix it.. thanks =)
-
:-o If you were infront of me i'd hug you just for the thought of Q-Gears. Seriously though, nice work. :)
-
:-o If you were infront of me i'd hug you just for the thought of Q-Gears. Seriously though, nice work. :)
Thanks.
-
2006/10/06
  * [ffvii] Add moving test object to unit manager. [Akari]
2006/10/04
  - [ffvii] Fix input was handled all by WindowManager and not given to other managers. [Akari]
v0.05b
2006/10/03
  * [ffvii] Add INC! (0x7A), INC2! (0x7B), DEC! (0x7C), DEC2! (0x7D) field opcodes support. [Akari]
  - [ffvii] Fix that unit has been displayed right after definition. now it displays only after setting its coords. [Akari]
  * [ffvii] Add direction display to default model cube. Testing purpose. [Akari]
  - [ffvii] Fix that XYZI opcode was 10 bytes length instead of 11 bytes. [Akari]
  * [ffvii] Add DIR (0xB3) field opcodes support. [Akari]
  + [ffvii] Now XYZI called only once. After the position is set you can't set it again. [Akari]
v0.05a
2006/10/02
  * [ffvii] Add XYZI (0xA5) field opcodes support. [Akari]
  * [ffvii] Add CHAR (0xA1) field opcodes support. Parameter not implemented. [Akari]
  * [ffvii] Add unit registration to UnitManager class. [Akari]
  * [ffvii] Add WAIT (0x24) field opcodes support. [Akari]
  - [ffvii] Fix that pointer shown before text finishes writing. [Akari]
  + [ffvii] Moved MemoryBank class to kernel. [Akari]
New version of windows binaries are at http://jrpg.ru/qgears_ffvii.zip
Please report about all crushes when moving on walkmesh. I already fix one of them, but they can appear again.
SVN has not been updated yet. I upload changes today evening.
-
Woo...
Good job Akari! I'll have to inspect what works and what doesn't and look into something for versioning.
This reminds me apart that I'm running a fever (cough cough sniffle)
... <brief download and hmm> ...
Akari just for this utter neat freaks sanity, it would be helpful to label the binaries for the revision, this way we can have an archive of binaries for quick bug introduction checking.
Cyb
-
Akari just for this utter neat freaks sanity, it would be helpful to label the binaries for the revision, this way we can have an archive of binaries for quick bug introduction checking.
The SVN revisions means nothing to me. They are just numbers of upload. The version I have - are the real thing implementation. For example 0.05 are all about unit moving, triggers handling
0.06 will be all about battle and random encounters
and so on. I have todo list and this versioning reflect it. =)
-
When I start Q-Gears 0.05, an error appears and it closes :?
-
I am feeling this thread is slowly spinning out of control. I've cleaned up some posts from a particular forum member, whom I'll be speaking too...
If you are having problems with Q-gears, I suggest you read this thread here (http://forums.qhimm.com/index.php?topic=5758.0).
Can you guys stay on topic please?
-
When I start Q-Gears 0.05, an error appears and it closes :?
What kind of error? More info please.
-
http://static.flickr.com/111/264239230_57cc1074bc.jpg?v=0
While moving the object in the field module (1st screen), I can "bump" in to the edges of the field and I "bumped" into the pillar(?) in the middle of the map but then the program locked up.
There is a screen shot in the above link.
Abit more progress then in the previous version, thanks.
Although on the next try I clicked Next and then clicked on the Map 74 option and was able to walk around on the map with no issues.
-
Here (http://christian59.ch.funpic.de/Error.JPG)'s Screenshot of the error.
-
While moving the object in the field module (1st screen), I can "bump" in to the edges of the field and I "bumped" into the pillar(?) in the middle of the map but then the program locked up.
There is a screen shot in the above link.
Okey. This error has been fixed. Thanks for report. By the way - here new version. Thanks to Synergy Blades for new opcode - we now can create labirinth with IDLCK (id_lock) opcode =)
I lock one triangle in STARTMAP - you can play with STARTMAP.xml and lock some more =)
[ffvii] v0.05c
2006/10/09
+ [ffvii] Change version number to v0.05c. [Akari]
* [ffvii] Add IDLCK (0x6D) field opcodes support. [Akari]
+ [ffvii] Redone walkmesh/access (we need posibility to deactivate triangles). [Akari]
+ [ffvii] Move walkmesh math to ffvii directory. [Akari]
- [ffvii] Fix fatal cycling when we try to cross triangle corner. [Akari]
New version of windows binaries are at http://jrpg.ru/qgears_ffvii.zip
-
You're doing great work Akari, is it just me or are you the most active coder in the Q-Gears team? :wink:
-
Akari pwnz :mrgreen: Another great fix for the Q-Gears project. I feel Q-Gears 1.0 being in the midst of fog. :) I'm learning the basic HELLO WORLD C++ thing so, maybe -eventualy- I can help with the project. lol.
(P.S. [PLEASE] STOP DELETING MY IMPORTANT POSTS!)
### MOD COMMENT ###
It's my job to decide what's important. If you have noticed from the mutiple stickies, some of our rules here are a bit "tighter" than your typical BBS. I just ask you use common sense when you post and don't rise the ire of the mods. We are quick to anger. Because you are new, I have shown tolerance. I simply ask to play nice, and engage the brain a little. That's all.
I corrected your last sentence up there in green. I would appreciate it, however, that you didn't tell me how to do my job. It's getting really annoying....
-halkun
Edit: Forgive me, i'm just a mod on several forums and a game designer. I'm nothing important and my topics on critical things don't matter. I don't mean to be rude but that's exactly how it looks to me. Do what you want with the messege, I can't stop an mod from doing something.
-
You're doing great work Akari, is it just me or are you the most active coder in the Q-Gears team? :wink:
It's because it's hard for the rest of us to keep up ^_^
Speaking of who, I was going through SVN and found my scriptdumping utility has vanished. (I was kinda using SVN to archive that.)
Sooner or later, we could stand to have a place to put helper programs and psudo-code that can/will get merged into q-gears . I'm not keen on using full blown branches just for utilitarian work. Things like Cyb's iso layer and other experiments, like my script dumper, and a half-writtern bytecode compiler need a place so others can hook into these "simple-yet-related" projects.
For example:
Akari, My method of parsing fieldscript differs from yours (a little), however, I'm sure some would like to use some of my "disconnected" code for utilities in the future. (Do you know how long it took me to create that huge 255 element enum for the opcodes? I'm suprised you didn't use it. "case MAPJUMP:" is a lot easier to read than "case 0x60"
What's your input?
Also, speaking of opcode parsing, a quick glance at your parsing code has a lot of repeating functions, for example the relation switches in Script.cpp. Is this something you are planning on cleaning up at a later time? Was there a plan to break Script.cpp into opcode "sections" (math, conditional, window, party) I recall something like that.
I just don't want you to work harder than you need to.
-
I actualy have a question for you. In the end of all plans, are you going to be changing on how certain systems work? For instance, the battle systems lighting effect VS the overworld and such? I'm just wondering since I have noticed some people complain about such systems, lol. It may be too early for this question but eh, my curiosity gets the best of me. -_-
Edit: "No, as it stands right now" is the first thing in that area. Things change in time, hence why I asked, and I mean EVER. Not at the end of this project, but the end of all plans. >_> I mean, that document talks more about the PS version then the PC, and look what we have here.
Edit 2: Okay, apparently then enhancements will never, ever, be done. It seems that way from the replys.
Edit 3: The rules here are WAY to restrictive. You wont be seeing me too often for that reason, it feels like someone is on a power trip.
-
How about Enhancements? I would like Bump mapping/MP3 Muisc/Per-pixel lighting/Particle effects....
No, as it stands right now, the clear goal is to get an engine up and running. Things like enhanced backgrounds, battle effects, and music are only considered if it's critical to the program. (For example, an increase in resolution to support newer systems.) We need it running as close to the original executables as possable. If you want to add your own effects or functions go ahead and fork the code and go wild. If it's orthogonal enough, we could add it back to the main trunk.
You obviously didn't read this:
http://forums.qhimm.com/index.php?topic=5556.0
-
In simple terms We want something working and reading the script first.
Enhancements are pointless unless that part works.
Without an active script engine clunking away playing with data, we can't find out what is going on.
Enhancements mean we might have a cool looking box that blinks but nothing to view at this time.
There is no Q-gears 1.0 it's pre alpha, it's a multi year project, we aren't even close to year 1 yet either. Perhaps in 6 months most of the small tools will work and the big script engine kernal will too. Maybe then, and that's maybe we'll have version 1.0. You should read the other sticky thread in the forum too (http://forums.qhimm.com/index.php?topic=5758.0). :D
-
when i open it, nothing happens
the console window opens, then the splash screen opens...but thats it.
-
Err - try pressing Space.
This is why what Cyb has been saying holds true - the current build really is not meant for hand-holding people through it. IMHO, there shouldn't be any error reporting unless you've also got the source to hand and have read through it (& understand it), which would answer questions like the above, as well as allow people to say "this isn't working, I'd check [X source file] because I think there's a memory allocation problem" or something (essentially, yeah, it closes off bringing up problems to those who know what they're talking about).
-
Here it is - week result. As always a lot of changes and a lot of additions.
[ffvii] v0.06a
2006/10/13
+ [ffvii] Change version number to v0.06a. [Akari]
* [ffvii] Implement PartyMenu loading when pressing S in FieldModule (and no text was shown). [Akari]
* [ffvii] Implement PC (0xA0) opcode and controllable entity. [Akari]
* [ffvii] Implement xml gateway loading (pc character doesn't set in given position yet). [Akari]
+ [ffvii] Changed coloring of triggers, walkmeshes and entities. [Akari]
+ [ffvii] Moved manager clearing from Dat file reader to FieldModule map loading. [Akari]
* [ffvii] Implement gateway activation and loading (pc character doesn't set in given position yet). [Akari]
* [ffvii] Read gateway info. [Akari]
2006/10/12
* [ffvii] Implement map loading on gateway activation. [Akari]
* [ffvii] Add Gateway class. Implement action on trigger activation. [Akari]
* [ffvii] Implement full collision box/trigger collision. [Akari]
+ [ffvii] Move trigger/collision check to trigger class. [Akari]
+ [ffvii] Move object collision to Model class (implement GetCollision()). [Akari]
* [ffvii] Create separate collision class. [Akari]
+ [ffvii] Move triggers and collision check to separate class. [Akari]
2006/10/11
* [ffvii] Implement test trigger/unit collision detection. [Akari]
New version of windows binaries are at http://jrpg.ru/qgears_ffvii.zip
I add few more maps so you can test few more of them (jump to them through dialog or through gateway).
But remind that if you try to move to next field after MD1_2 - game crush because it can't find next field.
-
Love your new object & gateway colour scheme. :-D Did you get the PM btw?
-
Wow, qgears has improved a lot on maps already. You can even load startmap without an xml and walk arround in a few of the maps you can jump from it!
Too bad there are still many unknown upcodes and missing features.
P.D.: Any specific reason you haven't updated the svn? I would like to play with the code. :P
-
Love your new object & gateway colour scheme. :-D Did you get the PM btw?
I stole coloring from your meteor :-P
Yup I got it, just dont have time answering yet.
Wow, qgears has improved a lot on maps already. You can even load startmap without an xml and walk arround in a few of the maps you can jump from it!
Too bad there are still many unknown upcodes and missing features.
For complete working of STARTMAP we need to know PRTYP, SLIDR opcode and a lot of opcodes in yuffie dialog. Many of them are don't known yet so it's up to Synergy Blades :-P
Ow.. for activation of dialog we need unit/unit collision =)
P.D.: Any specific reason you haven't updated the svn? I would like to play with the code.
I'll do this soon enough 8-)
-
I stole coloring from your meteor :-P
Yup I got it, just dont have time answering yet.
You are borrowing on a semi permanent basis. :)
Sheesh ... Well it's not too big of a deal, this weekend I will TRY wrangling the ISO code into Q-gears current existance.
halkun do you know what revision you uploaded your code at? Because you should be able to retrieve it based on the revision #
Some code wrangling is going to be needed soon I suspect.
Cyb
-
it was 70-something, I have a local copy I can re-upload.
-
For complete working of STARTMAP we need to know PRTYP, SLIDR opcode and a lot of opcodes in yuffie dialog. Many of them are don't known yet so it's up to Synergy Blades :-P
Ask, and ye shall receive (well, one new one at least), but it'll have to be posted here as no-one's deleted the redirect on PRTYP as per our request... :-P
* Opcode: 0xC8
* Short name: PRTYP
* Long name: Party Add
-- Memory layout
0xC8 - C
-- Arguments
const UByte C: Character ID to add.
-- Description
Adds a character to the party, as given by C. The character is added in the first given empty party slot (which can be set by PRTYE and an argument of FE for a slot); if there are no party members, the newly added character is the leader, if there is only leader, the newly added character occupies the second slot, and if there are two members, the character occupies the last slot. If the opcode is used when there is already a full party (with three members), the newly added party member occupies the last slot, displacing the party member already there.
It's probably worth noting that these ignore the locking and unavailability masks provided by MMBud and MMBLK/UK.
Halkun: I just grabbed the latest after having deleted the whole original folder I had containing Q-Gears, your script dumper is still there in trunk/utils/scriptdump, unless you're talking about something else?
-
I foudn a problem when compiling using VS2005:
In FieldModule::LoadMap(const u16& id) you call mpUnitManager->Clear().
The code generated by vs2005 sets the mapid (passed by reference) to 0xfeee when the destructor executes, so the value is lost!
I solved this by doing this:
FieldModule::LoadMap(const u16& tid)
{
u16 id=tid;
...
I also found a crash at UnitManager::CheckTriggers. There are script errors and it doesn't load any unit, so the unit vector is empty.
for (u8 i = 0; i < mGateways.size(); ++i)
{
if ( mUnits.size() <= mPC ) break;
mGateways[i]->CheckCollision(mUnits[mPC].position, collision);
}
...
I suppose this only happens because of the script errors, but anyway.
EDIT: I moved the if outside of the for whiule typing this because I thought it would work, but it seems it needs to be in it to work correctly.
-
Fixed. and commited to SVN.
-
Halkun: I just grabbed the latest after having deleted the whole original folder I had containing Q-Gears, your script dumper is still there in trunk/utils/scriptdump, unless you're talking about something else?
Oh, found it... Sorry. I was looking under /src I assummed Akari reverted it after that CapitalLetter thing.
-
In version 0.06, the same error occurs for me than with 0.05...(Image of the error (http://christian59.ch.funpic.de/Error.JPG))
EDIT: Now q-gears works for me, i dunno what error that was but now it starts normal. Good work Akari!
-
A lot of changes in this two weeks:
2006/10/25
* [ffvii] Add BTLON (0x71) field opcode support. [Akari]
* [ffvii] Add BTLTB (0x4B) field opcode support. [Akari]
[ffvii] v0.07a
2006/10/25
+ [ffvii] Change version number to v0.07a. [Akari]
* [ffvii] Add MPNAM (0x43) field opcode support. [Akari]
* [ffvii] Implement savemap map name storing. [Akari]
- [ffvii] Fix memory leak in xml to script converter (spesial opcode size was incorrect). [Akari]
* [ffvii] Implement Storing PC unit position and triangle in gamestate. Not use this though. Moved this to next version [Akari]
2006/10/24
* [ffvii] Implement BTLLK (0x0FFB) SPECIAL inner opcode. [Akari]
* [ffvii] Implement SPECIAL (0x0F) field opcode (without inner opcodes). [Akari]
2006/10/23
+ [ffvii] Rewrite script class. Make KERNEL Gamestate MemoryBank handling, not the FieldModule.
+ [ffvii] Make MemoryBank part of Gamestate.
* [ffvii] Add PRTYP (0xC8) field opcode support. [Akari]
+ [ffvii] make last active encounter table to be set as active. [Akari]
* [ffvii] Implement xml encounters loading. [Akari]
+ [ffvii] Return a lot of debug info (current coords, current triangle). [Akari]
+ [ffvii] Implement random encounters (Mechanics by Terence Fergusson). [Akari]
[ffvii] v0.06c
2006/10/20
+ [ffvii] Change version number to v0.06c. [Akari]
* [ffvii] Implement real Input handling (shown clickable window block all input to other managers). [Akari]
+ [ffvii] Return direction line for model. [Akari]
* [ffvii] Implement rough encounter (not the real scene, just encounter itself). [Akari]
* [ffvii] Implement encounter field info reading. [Akari]
2006/10/19
+ [ffvii] Add NULL check to Entity::DeleteScript(). [Akari]
* [ffvii] Add BATTLE (0x70) field opcodes support. [Akari]
+ [ffvii] Revert fix from 2006/10/14. Use RequestLoadMap in Gateway instead of LoadMap that is private now. [Akari]
[ffvii] v0.06b
2006/10/19
+ [ffvii] Change version number to v0.06b. [Akari]
+ [ffvii] Rewrite script class. Make ENUM case selection. [Akari]
+ [ffvii] Make single size for opcodes in converter and parser. [Akari]
2006/10/18
+ [ffvii] Make only 20 opcodes executed on one iteration. Initialization script must be less than this. [Akari]
+ [ffvii] Completly rewrite script class. Make it works more likein ffvii with single script buffer. [Akari]
2006/10/16
* [ffvii] Implement savemap map_id storing and loading.
* [ffvii] Create placeholder for battle.
- [ffvii] Fix Game was crushed when no PC entity defined. [Akari]
2006/10/14
- [ffvii] Fix LoadMap in field lose id given by reference when map resources was cleared. [Akari]
+ [ffvii] CheckTriggers in UnitManager now takes unitId as argument because we need check not only PC. [Akari]
As I have acceess to File release I upload new binaries here http://sourceforge.net/projects/q-gears
I don't know how to upload changes to SVN since there are a lot of changes.... upload little later.
-
Whenever I try running this new version it crashes instantly soon after displaying the console and window.
Here's the game log, doesn't look that helpful though:
[21:19:44] Set current renderer: OpenGL.
[21:19:44] SDL init begin
[21:19:44] SDL_INIT_VIDEO initialized
[21:19:45] SDL video mode set 640x480, 16 bit SDL_OPENGLBLIT | SDL_HWSURFACE
[21:19:45] Got 32 bpp (8888), 24 depth, 8 stencil
[21:19:45] SDL init complete
[21:19:45] OGL Vendor: ATI Technologies Inc.
[21:19:45] OGL Renderer: RADEON X850 XT Platinum Edition x86/SSE2
[21:19:45] OGL Version: 2.0.5949 WinXP Release
[21:19:45] OGL Extensions: GL_ARB_multitexture GL_EXT_texture_env_add GL_EXT_compiled_vertex_array GL_S3_s3tc GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_multisample GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_transpose_matrix GL_ARB_vertex_blend GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ARB_draw_buffers GL_ATI_draw_buffers GL_ATI_element_array GL_ATI_envmap_bumpmap GL_ATI_fragment_shader GL_ATI_map_object_buffer GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_ATI_texture_mirror_once GL_ATI_vertex_array_object GL_ATI_vertex_attrib_array_object GL_ATI_vertex_streams GL_ATIX_texture_env_combine3 GL_ATIX_texture_env_route GL_ATIX_vertex_shader_output_point_size GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_object GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_texgen_reflection GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_EXT_vertex_shader GL_HP_occlusion_test GL_NV_blend_square GL_NV_occlusion_query GL_NV_texgen_reflection GL_SGI_color_matrix GL_SGIS_generate_mipmap GL_SGIS_multitexture GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays GL_WIN_swap_hint WGL_EXT_extensions_string WGL_EXT_swap_control
[21:19:45] GLU Version: 1.2.2.0 Microsoft Corporation
[21:19:45] Set SDL input handler.
The time is an hour slow on the log too :-P
-
New version.
[ffvii] v0.08
2006/11/10
+ [ffvii] Change version number to v0.08. [Akari]
* [ffvii] Add solid state to unit. [Akari]
* [ffvii] Implement savemap pc coords loading after gateway. Slightly redone position set mechanics. [Akari]
* [ffvii] Implement xml walkmesh loading. [Akari]
* [ffvii] Implement GetVector3 parse method to XmlFile for coords parse (xyz="999 999 999"). [Akari]
2006/11/09
- [ffvii] Fix battle encounter and trigger checked even if we are not moving. [Akari]
* [ffvii] Implement restore position after battle. [Akari]
* [ffvii] Implement storing and loading pc coords set bool value. [Akari]
* [ffvii] Move all XML loading from field to DatXmlFile loader. [Akari]
* [ffvii] Create DatXmlFile class that handles field XML loading. [Akari]
* [all] Create XmlFile class that handles basic XML operations. [Akari]
2006/11/07
* [ffvii] Implement unit/unit colliding. [Akari]
2006/11/03
* [xeno] Add WalkMesh loader to FieldModule and display walkmesh. [Akari]
* [xeno] Add FieldModule placeholder alonf with unit manager (as in ffvii). [Akari]
* [xeno] Add ArchiveFile class that handles archives. [Akari]
2006/11/02
* [ffvii] Implement dialog activation. [Akari]
- [ffvii] Fix small error in WindowManager. (pointer position was reseted even if we create not ask window) [Akari]
* [ffvii] Implement unit/unit collision detection. [Akari]
* [ffvii] Switch to ODE collision detection for triggers and units. [Akari]
2006/10/27
* [ffvii] Add triangle that shows gateway and ladder to KERNEL. [Akari]
Windows binaries available here: http://sourceforge.net/projects/q-gears
-
Ooh cool, you rock Akari, I'm really looking forward to the day you can commit all this to svn. :wink:
-
Ooh cool, you rock Akari, I'm really looking forward to the day you can commit all this to svn. :wink:
Done =)
-
hm, with ODE being lots of things, I was wondering if it was "Open Dynamics Engine", or something else... but I suppose I will know when I try to use that one. :P
-
New release.
[ffvii] v0.09
2006/11/22
+ [ffvii] Change version number to v0.09. [Akari]
+ [ffvii] Optimize FieldModule a little. Remove unneeded pointers and manual memory allocation. [Akari]
* [ffvii] Implement Fade on map load and unload. [Akari]
+ [ffvii_content] Change map STARTMAP.xml. Add load CHORACE choise in Yuffie dialog. [Akari]
* [ffvii_content] Add CHORACE map by request of Synergy Blades as very hard with a lot of different background animation. [Akari]
- [ffvii] Fix DatXmlFile when there is no XML. [Akari]
2006/11/22
* [ffvii] Add FADEW (0x6C) field opcode support. [Akari]
* [ffvii] Add FADE (0x6B) field opcode support. [Akari]
* [ffvii] Add Fade effect to field module. [Akari]
* [ffvii] Add ColorOverlay to Kernel. [Akari]
+ [ffvii_content] Change map ELEVTR1.xml. Add gateway back to NMKIN_1. [Akari]
+ [ffvii_content] Change map STARTMAP.xml. Make battle be lock by default. [Akari]
+ [ffvii_content] Change map STARTMAP.xml. Remove IDLCK opcode (we dont need it since we use our own walkmesh). [Akari]
+ [ffvii_content] Change map MD1STIN.xml. Remove timer and all text scripts. [Akari]
+ [ffvii_content] Change map NRTHMK.xml. Add Triangle lock as on real map. Remove our own gateway. [Akari]
+ [ffvii_content] Add simple sprite animation to MD1_2.xml. [Akari]
* [ffvii_content] Add NMKIN_1 and ELEVTR1 map. [Akari]
- [ffvii] Fix SetTriangleAccess() and SetEncounterTable() in UnitManager wrong sanity check. [Akari]
- [ffvii] Fix sprite animation on same layer (when all sprites located on 2nd layer). [Akari]
2006/11/21
* [ffvii] Implement showing/hide walkmesh and unit collision. [Akari]
* [ffvii] Add BGOFF (0xE1) field opcode support. [Akari]
* [ffvii] Add BGON (0xE0) field opcode support. [Akari]
* [ffvii] Add BGCLR (0xE4) field opcode support. [Akari]
* [ffvii] Implement background swich on/off (layer separately). [Akari]
* [ffvii] Implement sprite background animation. [Akari]
* [ffvii] Implement 2nd Layer. [Akari]
+ [ffvii] Rewrite Display blending and geometry to be more like one in psx. [Akari]
2006/11/17
* [ffvii] Implement basic Background 1st layer loading. [Akari]
- [ffvii] Fix Vram image aligment in Vram buffer for both tim and mim. [Akari]
2006/11/16
* [ffvii] Add a lot of log info about initialization of different part of Kernel. [Akari]
+ [ffvii] Change tim and mim loading using Vram. [Akari]
* [ffvii] Create Vram for tim and mim loading. Always allocate 1mb of memory for each texture loading. More efficient than previous method in some way. [Akari]
2006/11/15
* [ffvii] Add mim file loader. [Akari]
+ [ffvii] Moved Kernel::Init() calling outside constructor, because we need constructed Kernel in Graphic initialization. [Akari]
-
Are you going to be implementing a view window soon? Even though it would be nice to run in 640x480, the actual field window is only 320x240, (or around there, I think I'm +/- a few pixels) and we really don't have the graphical data to display them full screen like that.
-
*claps* Very well done, now we have some graphics to have fun with eh? ^_^ The only thing I noticed that doesn't seem to be working correctly is the density of certain areas. Regardless, this must have not been easy ey? *huggles the 0.09 version*
-
Are you going to be implementing a view window soon? Even though it would be nice to run in 640x480, the actual field window is only 320x240, (or around there, I think I'm +/- a few pixels) and we really don't have the graphical data to display them full screen like that.
Maybe in next version where I'm going to implement real positioning, scaling and scrolling of background and walkmesh (among many others less visible changes).
By the way I update todo topic so anyone can see what am I planning to do in future.
The only thing I noticed that doesn't seem to be working correctly is the density of certain areas.
You mean that walkmesh doesn't fit background? I haven't working on that yet.
There are few troubles with background (look at CHORACE)... and we dont understand palette animations yet =(
Ow.. and I don't load changes in SVN yet. I do it tomorrow.
-
Akari good job .. I wish I was as busy as you at this.
Busy busy busy Akari. All right I suppose I need to actually finish that ISO stuff (it's not too bad really).
Are you going to be implementing a view window soon? Even though it would be nice to run in 640x480, the actual field window is only 320x240, (or around there, I think I'm +/- a few pixels) and we really don't have the graphical data to display them full screen like that.
Do you mean the 'view port' or user view port? Hmmmm.
That's a nasty complicated problem actually :(
Cyb
-
Are you going to be implementing a view window soon? Even though it would be nice to run in 640x480, the actual field window is only 320x240, (or around there, I think I'm +/- a few pixels) and we really don't have the graphical data to display them full screen like that.
Can't you just scale everything to 2x? I know the backgrounds will look pixelated (texture filtering could be used but then the pink/green/yellow areas whatever colors it uses might be a problem), but it seems better than just showing a huge black border arround :P
Anyway, this is getting really nice... :)
-
Yeah, the walkmesh is what I ment. Regardless, it's really good. The elevator for example seems PERFECT with the walkmesh. It's very nicely done. This seems to be a major step in the development of Q-Gears, and i'm all over being a fan. :mrgreen: Yes, it's true, I like to look at pretty graphics rather then the code, but this is great none the less. Keep up the good work! I'll keep bouncing some FF7 fans to these forums, maybe a few will actualy know something and offer help. :-o
-
Good work Akari, I like the new version very much!!
But sometimes the walkmesh doesnt match correctly with the backgrounds, as you can see in this two screenshots: Screen 1 (http://christian59.ch.funpic.de/Screenshots/qgears1.JPG); Screen 2 (http://christian59.ch.funpic.de/Screenshots/qgears2.JPG)
-
Good work Akari, I like the new version very much!!
But sometimes the walkmesh doesnt match correctly with the backgrounds, as you can see in this two screenshots: Screen 1 (http://christian59.ch.funpic.de/Screenshots/qgears1.JPG); Screen 2 (http://christian59.ch.funpic.de/Screenshots/qgears2.JPG)
Well ...
Please read this Reply (http://forums.qhimm.com/index.php?topic=6218.msg78857#msg78857) to this question/suggestion/bug report (http://forums.qhimm.com/index.php?topic=6218.msg78853#msg78853).
Also viewing this thread (http://forums.qhimm.com/index.php?topic=6143.0) will be helpful as well.
-
The only thing I noticed that doesn't seem to be working correctly is the density of certain areas.
You mean that walkmesh doesn't fit background? I haven't working on that yet.
-
A quick check, after seeing the screen shots on the sourceforge site.
To get the field backgrounds do I need to have Qgears extracted to the FF7 directory?
-
q-gears/ff7 needs the PS1 game files, pc data files aren't supported yet
-
Fuuff. There is no more ScriptManager and UnitManager. Now there is only one ObjectManager.
Three days of rewriting finally finished =)
Now the work with it will be much more easy.
And.. I slightly changed my to do. I think due to a lot of working it will be finished only to end of year... and it will be a new year present (almost fully workable 1st mission. all maps, correct walkmesh size and a lot more).
// [ffvii] v0.10
! [ffvii] Add all 1st mission location.
! [ffvii] Get ELEVTR1 level work correctly.
! [ffvii] Implement line opcode.
! [ffvii] Implement scrolling opcodes.
! [ffvii] Implement walkmesh and background scrolling. (SCR2D SCR2DC).
! [ffvii] Implement screen and loading of screen related data from DAT (coords).
- [ffvii] Rework input module. Make it reported only pressed buttons all the time. Not the event.
- [ffvii] Rewrite and optimize UnitManager/ScriptManager.
! [ffvii] Make Walkmesh separate class/struct like trigger that can draw itself.
! [ffvii] Try to move walkmesh moving to ODE. Is it needed?
! [ffvii] Move unit to separate class.
! [ffvii] Make whole game state saved when go to battle (script state, unit state).
- [ffvii] Do something with a lot of printf in script.
- [ffvii] Make waiting type of opcodes allowed in starting script.
If someone wants to add some visible module till the 0.10 release date it will be great.
ps: einherjar, some progress with world map? Can you finished it till the end of december? :-P
-
ps: einherjar, some progress with world map? Can you finished it till the end of december? :-P
World *geometry* will be viewable in the wm module by the end of the month.
For texturing, it will depends on how well/fast I understand the way it should be done.
-
Hey I have tried to build the svn source, but I'm getting lots of errors from missing members, most of them from Geometry, TotalGeometry and Display, I'm not sure if it's some wrong file in the project or what
-
Hey I have tried to build the svn source, but I'm getting lots of errors from missing members, most of them from Geometry, TotalGeometry and Display, I'm not sure if it's some wrong file in the project or what
Yes: xeno does not compile anymore :|
I fixed some errors, but was not able to fix them all -- I don't know the code of xeno/ and cannot test it...
So I've suspent compilation of q-gears-xeno on linux, until the situation is stabilized.
Current svn version does compile, but only q-gears-ffvii; q-gears-xeno is skipped.
-
Xeno == Akari stuff.
However I'm stuck right now (IE snowed in) so I'll be a bit busy digging the access route out of the house (IE the driveway). Not like I can GO anywhere as the roads aren't cleared enough to pass. I think I'll get more time soonish. Right now I deciphering an MSDOS packed format executable. Gah it's anoying!
However when done I should be able to get some useful information out of it.
Cyb
-
Not perfectly, but fits. I leave it this way for this release (0.10) And start to work on scrolling.
(http://omake.ru/bakari/q-gears/q-gears.0.09b_1.jpg)
(http://omake.ru/bakari/q-gears/q-gears.0.09b_2.jpg)
ps: Someone can add this things to q-gears website to show our progress. =)
pss: 2 einherjar: Show even minor changes in view. This can keep people interest =)
And don't forget to write Changelog :-P
-
Awesome akari! This is great work :-P It looks accurate enough for me, what's wrong with it? :|
-
Not perfectly, but fits. I leave it this way for this release (0.10) And start to work on scrolling.
Great hmm I might be able to tweak it some. I suppose putting a fake window port somewhere on the screen might be interesting as well.
IE instead of actually scrolling the background scroll a highlighting edge window for testing purposes. I think that will give us a clue how it worked originally.
ps: Someone can add this things to q-gears website to show our progress. =)
pss: 2 einherjar: Show even minor changes in view. This can keep people interest =)
And don't forget to write Changelog :-P
That would be web miester's job.
Erstwhile if you want me to add some detailed comments to the code that reads the background information I can do that much at the very least.
Weren't we going to use doxygen? I have to go and look at how that is supposed to work.
Cyb
-
Nice work Akari :-)
-
I've added .MAP file loading and some data structure to handle world map in q-gears
I've also modified world map module to make it draw the said structures:
(http://lrde.epita.fr/~benoit/q-gears/worldmap-wireframe.png)
I admit it's not really sexy :| but it's a first step. I will immediately start working on
speeding up the whole a little: it's around 4 fps on my P4 2.5Ghz / GeForce 6600 GT...
-
Yes... needs to be 30 fps to at least be on par with FF7's field speed. :)
Speed ups
Abuse FF7 type fade geometry.
Use multiple DLists in sections, then use said DList when that section is viewed.
Add a horizon (IE fake curvature like FF7 used part of fade geometry).
If I remember correct FF7 loaded sections of the map and unloaded sections of the map as one traveled over it. It always loaded in the direction you were going and dumped in the direction you had been. I believe it only showed a 5x5 grid of sections and cached left over sections. This kept loading mostly in the background as you moved through the map.
Something like
000 001 002 003 004
040 041 042 043 044
080 081 082 083 084
0C0 0C1 0C2 0C3 0C4
100 101 102 103 104
If you moved for example from 082 to 043 the top row would be the wrap around data FC1 FC2 FC3 FC4 FC5, then 005 045 085 0C5 would be loaded.
000 040 080 0C0 100 101 102 103 104 would be dumped or left in the cache as long as possible.
That's the idea at least I think they used.
Each section begins on a 2K boundry in the PS1 right? If so that means they used a sector seek to find data chunks (par for the system they used).
Cyb
-
Wow... keep it up and we can do anything =)
There still a lot of time till the 0.10 release.
I finished with scrolling and screen based function (1st implementation) and start working with LINE and LADDER opcodes. (Synergy Blades - stay alert.. I will come with a lot of questions :-P) This opcodes needed for moving through some maps in first mission :|
-
Yes... needs to be 30 fps to at least be on par with FF7's field speed. :)
Speed ups
Abuse FF7 type fade geometry.
Use multiple DLists in sections, then use said DList when that section is viewed.
Add a horizon (IE fake curvature like FF7 used part of fade geometry).
I've added a "low-level display-oriented not-editable" mesh data structure that uses a
prebuilt vertex array. With this I get 60/90 fps on my machine. It is a GL-oriented structure,
in the sense that it is *not* an interleaved array, which is the prefered way of DirectX;
I don't know if it may be a problem...?
I am planning to do frustum culling, which is totally equivalent to what you propose.
I've built the bounding box of each mesh/cell, all we need is a camera with an explicit
frustum volume.
If I remember correct FF7 loaded sections of the map and unloaded sections of the map as one traveled over it.
This kept loading mostly in the background as you moved through the map.
This was/is certainly a way to minimize loading time (CD access actually) and memory usage (PS1... :) ).
It is pretty elegant, but right now I will focus on textures, as memory is not really a problem today,
and loading time is ... ah... "acceptable" when using PSX CD, and invisible using PC/HD version.
-
I finished my part already and now merging changes with trunk.
Not that much was finished, but this is all that can be done till the ends of the year.
-
Hmm. there is a trouble with worldmap module. It crash the game sometimes. When I run it from my working directory - everithing fine, but when I copy it (the whole dir) somewhere it crushes somewhere during LZS extruction. I turn it off for now. (comment M button handling in DisplayTest).
-
New version of binaries on sourceforge.
Changes:
2006/12/13
- [ffvii] Fix init_state in WindowManager was u8 size and can't handle string larger than 255 symbols. [Akari]
* [ffvii] Add LADER (0xC2) field opcode support. [Akari]
* [ffvii] Add ladder mode and ladder moving to ObjectManager. [Akari]
2006/12/12
+ [ffvii_content] Level ELEVTR1 now can be passed to next map and back using LINE and MAPJUMP opcodes. [Akari]
* [ffvii] Add LINON (0xD1) field opcode support. [Akari]
+ [ffvii] Make that PositionByXZ positioned entity in top triangle with this coords. [Akari]
- [ffvii] Fix MAPJUMP was not working correctly. Missed KERNEL coords setting. [Akari]
* [ffvii] Add LINE (0xD0) field opcode support. [Akari]
+ [ffvii] Create OnEnter and OnLeave action for triggers, gateways and line. [Akari]
2006/12/11
- [ffvii] Fix small error with vector for WaitForScroll entity. (was used s16 instead of s8) [Akari]
+ [ffvii] Make SCR2DC (0x66) smooth scrolling with slow start and end. [Akari]
2006/12/08
* [ffvii] Implement screen and loading of screen range DAT. [Akari]
* [ffvii] Add SCRLW (0x67) field opcode support. [Akari]
+ [ffvii] Remove poping of Field module when go to battle. Now state of field stored corectly. [Akari]
+ [ffvii_content] Change walkmesh and counter to show entity 1 triangle is. [Akari]
* [ffvii] Add GETAI (0xB9) field opcode support. [Akari]
+ [ffvii_content] Add CC to STARTMAP.xml to switch player entity to Akari when talk to it. [Akari]
* [ffvii] Add CC (0xBF) field opcode support. [Akari]
+ [ffvii_content] Add MENU2 to MD1STIN.xml like in the real map. [Akari]
* [ffvii] Add MENU2 (0x4A) field opcode support. [Akari]
+ [ffvii_content] Add PRTYE to MD1STIN.xml like in the real map. [Akari]
- [ffvii] Fix wrong character slot check in PartyMenu. [Akari]
- [ffvii] Fix wrong matrix pushing in gui elements. [Akari]
* [ffvii] Add PRTYE (0xCA) field opcode support. [Akari]
2006/12/07
+ [ffvii_content] Add UC opcodes and disables character moving until scrolling finishes. [Akari]
* [ffvii] Add UC (0x33) field opcode support. [Akari]
+ [ffvii_content] Add SCR2DC and SCR2D opcodes to MD1STIN.xml like in the real map. [Akari]
+ [ffvii_content] Add start dialog to STARTMAP.xml that describes last changes. [Akari]
* [ffvii] Add SCR2DL (0x68) field opcode support. [Akari]
- [ffvii] Fix that GetMemoryBank u16 in Kernel do not returned immediate value larger than 254. [Akari]
* [ffvii] Add SCR2DC (0x66) field opcode support (linear scrolling for now). [Akari]
* [ffvii] Add SCR2D (0x64) field opcode support. [Akari]
* [ffvii] Add screen border to field module. [Akari]
* [ffvii] Sync background scrolling and walkmesh scrolling. [Akari]
* [ffvii] Add scrolling background posibility to field module. [Akari]
2006/12/06
+ [ffvii_content] Add for more choises to Yuffie dialog for mapjump to newly added maps for testing. (this will be remove before release) [Akari]
* [ffvii_content] Add NMKIN_2, NMKIN_3 files for 0.10 release. [Akari]
* [ffvii] Add perspective matrix loading from Camera in DAT file.. [Akari]
2006/12/01
+ [ffvii] Combine UnitManager and ScriptManager. Create ObjectManager that manages all object on field. [Akari]
2006/11/28
+ [ffvii] Remove printf when window status updates. [Akari]
+ [ffvii] Change output from Script from prinf to Logger and add flag to config "DUMP_SCRIPT=false". If setted to "true" output all script to log file. [Akari]
2006/11/28
+ [ffvii] Change entity class makes sync opcodes alowed in init script. [Akari]
2006/11/27
+ [ffvii] Remove unnesessary DropInput methods in UnitManager and FieldModule. [Akari]
+ [ffvii] Make move in UnitManager works with repeat input event. [Akari]
+ [all] Cleanup input module alittle. [Akari]
+ [all] Rework input module. Make it reported not only FIRST_PRESS and RELEASE event but REPEAT too. [Akari]
SVN was updated last weekend.
-
When I run it from my working directory - everithing fine, but when I copy it (the whole dir)
somewhere it crushes somewhere during LZS extruction.
It looks like a file access / path problem. Could you please show the last lines of the log file?
Does it SEGV or does an assertion fail?
Could you precise the "crashes sometimes": does it always crash when running in a specific directory, and does it never crash when running in another?
-
When I run it from my working directory - everithing fine, but when I copy it (the whole dir)
somewhere it crushes somewhere during LZS extruction.
It looks like a file access / path problem. Could you please show the last lines of the log file?
Does it SEGV or does an assertion fail?
Could you precise the "crashes sometimes": does it always crash when running in a specific directory, and does it never crash when running in another?
Nope it's not file access trouble. It writes LOGGER->Log("Warning: extract failed, this is not lzs!"); many many times. Nothing else. Crushes sometimes during this.
I really don't know how could it be. I move everything.. all librarys, files... and it crushes =|
Not trying to debug it though.
If you post description of format on wiki - I could try to solve this.
-
Does it SEGV or does an assertion fail?
Could you precise the "crashes sometimes": does it always crash when running in a specific directory, and does it never crash when running in another?
It writes LOGGER->Log("Warning: extract failed, this is not lzs!"); many many times. Nothing else.
This is "normal", considering that the size of the lzs section is not known a priori, so the lzs extractor
is asked to guess all alone the size of the data to extract by reading the first bytes in the header.
Crushes sometimes during this.
OK will check this.
-
You should also make sure all files get loaded correctly, maybe it tries to load a lsz you haven't copied from the psx cd, or maybe some dir is wrong...
-
You should also make sure all files get loaded correctly,
Actually we do not have a way yet to check if a File was opened
correctly except looking at the log file. Or checking the file size,
but it supposes that it is known at compile time. Hmmm, interesting
point.
maybe it tries to load a lsz you haven't copied from the psx cd,
(I'm directly accessing the PSX CDs in my CDROM drive)
OK I think I have tracked it down. I've launched valgrind, and (... drums ...):
== 1 errors in context 2 of 37:
== Mismatched free() / delete / delete []
== at 0x401CCBC: operator delete(void*) (vg_replace_malloc.c:244)
== by 0x808E9C6: MapFile::ReadMap(StdString::CStdStr<char> const&, unsigned, unsigned, unsigned) const (MapFile.cpp:57)
Indeed: in revision 109, to make VS2005 build q-gears, the following (ffvii/worldmap/MapFile.cpp):
uint8_t cell_data[sizeof_cell];
was replaced by:
uint8_t *cell_data = new uint8_t[sizeof_cell];
// ...
delete cell_data; // should be `delete [] cell_data'
Ouuups :-D
Did the former code generate an error or a warning in VC++? Let me know so that I will not rewrite it (g++ does not complain at all)
Akari, could you give it another try? Thanks in advance!
If you post description of format on wiki - I could try to solve this.
Yeah, I get the message :wink: As soon as I have a write access (which I just have requested), I describe it in the wiki.
-
Oh yeh... vc isn't able to allocate a fixed-size array from a variable... :/
c:\qgears\svn_original\src\ffvii\worldmap\mapfile.cpp(38) : error C2057: expected constant expression
c:\qgears\svn_original\src\ffvii\worldmap\mapfile.cpp(38) : error C2466: cannot allocate an array of constant size 0
c:\qgears\svn_original\src\ffvii\worldmap\mapfile.cpp(38) : error C2133: 'cell_data' : unknown size
EDIT: updated the vs2005 files for the latest source changes and added a missing "return ret;"
-
Yeah, I get the message :wink: As soon as I have a write access (which I just have requested), I describe it in the wiki.
Done:
http://wiki.qhimm.com/FF7/WorldMap_Module
-
What would be cool is to see a render of the whole worldmap with the walkmesh attibutes coloring the polygons. That may answer some questions over what each does....
-
What would be cool is to see a render of the whole worldmap with the walkmesh attibutes coloring the polygons. That may answer some questions over what each does....
Hmmm... so you want a 2d map with polys colored based on the walkInfo attribute of the triangles?
0x20 = Green
0x21 = Yellow
0x22 = Orange
0x23 = Red
Would that work? I think I can just write a quick util that will export a POV scene for that. (Quick is relative I might point out ;) ).
einherjar
As for 0x21 and 0x22 being the same, that might be a tiny bronco difference on the water. I know one can't walk over mountains etc on the land.
Was there any information for Field locations in the walk map? For example Costa Del Sol, Junon, North Corel Mountains, Kalm etc. are all Field locations that are referenced from the world map somehow. Where are the models coming from that are on the world map? Could that be the BOT files? I wonder if those are similar to the entities used in the field areas. IE you run into the entity on the world map it executes a MAPJUMP for the field location. It would make sense to do this on the world map. The BOT file may contain the battle information for the field as well. IE load what battle scene etc. I may have to do some checking with the rest of this.
Cyb
-
New version at last =)
[ffvii] v0.11
2007/01/26
+ [ffvii] Change version number to v0.11. [Akari]
+ [ffvii] Change help to all modules. [Akari]
- [ffvii] Fix error when we add more and more elements to global g_SpritePoly from BackgroundManager
when called it constrictor. [Akari]
2007/01/25
- [ffvii] Fix bug when two field modules called togather. When one was deleted,
static script member was also deleted, making it unavailable for second field module. [Akari]
+ [ffvii] Make Field as start module to q-gears. [Akari]
- [ffvii] Fix conditional jump opcodes. [Akari]
2007/01/24
- [ffvii] Fix ladder movement to start position. [Akari]
* [ffvii] Add AXYZI (0xC1) field opcode support. [Akari]
- [ffvii] Fix TimFile loader. [Akari]
- [ffvii] Fix background viewing (transparency issue). MimFile loader was incorrect. [Akari]
2007/01/23
+ [ffvii_content] Add NMKIN_4 and NMKIN_5 maps. [Akari]
* [ffvii] Add JUMP (0xC0) field opcode support. [Akari]
* [ffvii] Add base implementation of jump mode. [Akari]
+ [ffvii] LADER now is waiting-type opcode. [Akari]
* [ffvii] Implement ladder climbing buttons. [Akari]
2007/01/22
+ [ffvii] Make line script activation like Synergy Blades says. [Akari]
* [ffvii] Add SOLID (0xC7) field opcode support. [Akari]
* [ffvii] Add TLKR2 (0xD6) field opcode support. [Akari]
* [ffvii] Add SLDR2 (0xD7) field opcode support. [Akari]
* [ffvii] Add TALKR (0xC7) field opcode support. [Akari]
* [ffvii] Add SLIDR (0xC6) field opcode support. [Akari]
+ [ffvii] Gamestate and Database now accessable directly like KERNEL and not accessible from KERNEL anymore. [Akari]
* [ffvii] Add IFKEYOFF (0x32) field opcode support. [Akari]
* [ffvii] Add IFKEYON (0x31) field opcode support. [Akari]
* [ffvii] Add struct that holds state of game button to KERNEL. [Akari]
2007/01/19
* [ffvii] Add IFKEY (0x30) field opcode support. [Akari]
+ [all] Add IsButtonPressed method to InputFilter class. [Akari]
+ [ffvii] ODE removed. Implement range collision detection instead. [Akari]
2007/01/18
+ [ffvii] Make trigger activation works with distance instead of ODE. [Akari]
+ [ffvii] Move WalkMeshTriangle struct to separate class that derives from Actor. [Akari]
2007/01/12
* [ffvii] Add mark triangle animation to MarkTriangle class. [Akari]
+ [ffvii] Move MarkTriangle struct to separate class that derives from Actor. [Akari]
* [ffvii] Add showing gateway mark triangle from DAT and XML. [Akari]
* [ffvii] Add SCRCC (0x65) field opcode support. [Akari]
2007/01/11
* [ffvii] Add reading of extra mark triangle from XML. [Akari]
* [ffvii] Add MPJPO (0xD2) field opcode support. [Akari]
2007/01/10
* [ffvii] Add reading of extra mark triangle from DAT. [Akari]
* [ffvii] Implement showing triangle that shows gateway on map. [Akari]
2007/01/09
+ [ffvii] Made all Actor->Draw constant method. [Akari]
* [ffvii] Implement that camera follows character. [Akari]
Additionally I add new screenshots to sourceforge and activate worldmap module.
-
VERY good work, the new version!! :lol:
But at the point where you are going to place the bomb, the controls are wront (UP->DOWN,...)
-
VERY good work, the new version!! :lol:
But at the point where you are going to place the bomb, the controls are wront (UP->DOWN,...)
It works just as it has been done. UP -> increase X coord.
! [ffvii] Implement loading directional keys from XML.
! [ffvii] Implement map related directional keys handling.
This things are planned to next release.
-
Hey guys, I'm the new kid in the neighborhood...
I stumbled over your exciting Q-Gears project some days ago (after the 0.11 release) and after checking out the Win32 executable, I wanted to look around in the code... the FAQ on your homepage sounds so inviting to do so, maybe I could be a little help someday.
But the code in the SourceForge SVN does not seem to be up to date?
The SVN browser says the last submission was made 4 weeks ago, but hasn't 0.11 been released on January, 26th?
I checked out the trunk, compiled it without any problems and after some stracing, discovering the game.log file and copying around some /data stuff it didn't segfault anymore. ;)
But the resulting binary also seems to be far more incomplete than the 0.11 Win32 executable I downloaded earlier.
Am I doing something wrong?
I used
svn co https://q-gears.svn.sourceforge.net/svnroot/q-gears q-gearsas SourceForge suggests.
Thanks in advance and keep up the awesome work!
-
That's because Akari hogs the code. It's forgivable with all the work done on that side.
Akari... Update SVN please :P
-
That's because Akari hogs the code. It's forgivable with all the work done on that side.
Akari... Update SVN please :P
Mmm I experience some Tortoise SVN trouble lately. It doesnt want to upload all files at once. It works for one file, but doesn't want to handle them all together =(
-
Looks like they changed the directory management a little bit on Sourceforge.
Try doing a new checkout of the trunk....
svn co https://q-gears.svn.sourceforge.net/svnroot/q-gears/trunk q-gears
you used to not have to put "trunk" in the https// link, if I remember.
Pull down a new copy, merge your changes and try uploading again, of that doesn't work, you may have to try a command line version of SVN
-
that's just the "standard" naming :p
./branches
./tags
./trunk
if you never branched or tagged the source, then the other two will be empty... anyway Akari you can get the svn client from http://subversion.tigris.org/ get the win32 exe isntaller. The .svn data is compatible so you can just to "svn commit" from a cmd prompt. (svn update to update, etc)...