Author Topic: Q-Gears.0.11  (Read 40094 times)

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: Q-Gears.0.09
« Reply #50 on: 2006-11-24 23:00:47 »
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; Screen 2

Well ...
Please read this Reply to this question/suggestion/bug report.
Also viewing this thread will be helpful as well.

nope

  • *
  • Posts: 56
  • nope
    • View Profile
Re: Q-Gears.0.09
« Reply #51 on: 2006-11-25 05:31:56 »

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

The Skillster

  • *
  • Posts: 2284
  • Loving every Final Fantasy
    • View Profile
Re: Q-Gears.0.09
« Reply #52 on: 2006-11-30 19:11:23 »
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?

gigaherz

  • *
  • Posts: 105
    • View Profile
    • gigaherz's shitty stuff
Re: Q-Gears.0.09
« Reply #53 on: 2006-11-30 19:19:29 »
q-gears/ff7 needs the PS1 game files, pc data files aren't supported yet

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: Q-Gears.0.09
« Reply #54 on: 2006-12-01 10:22:03 »
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).
Quote
// [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

einherjar

  • *
  • Posts: 38
    • View Profile
Re: Q-Gears.0.09
« Reply #55 on: 2006-12-01 11:09:16 »
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.

gigaherz

  • *
  • Posts: 105
    • View Profile
    • gigaherz's shitty stuff
Re: Q-Gears.0.09
« Reply #56 on: 2006-12-01 22:04:48 »
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

einherjar

  • *
  • Posts: 38
    • View Profile
Re: Q-Gears.0.09
« Reply #57 on: 2006-12-01 23:04:16 »
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.
« Last Edit: 2006-12-01 23:26:02 by einherjar »

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: Q-Gears.0.09
« Reply #58 on: 2006-12-02 02:06:43 »
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

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: Q-Gears.0.09
« Reply #59 on: 2006-12-06 16:53:00 »
Not perfectly, but fits. I leave it this way for this release (0.10) And start to work on scrolling.




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

nope

  • *
  • Posts: 56
  • nope
    • View Profile
Re: Q-Gears.0.09
« Reply #60 on: 2006-12-06 21:04:32 »
Awesome akari! This is great work :-P It looks accurate enough for me, what's wrong with it? :|

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: Q-Gears.0.09
« Reply #61 on: 2006-12-06 21:51:30 »
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

Hades

  • *
  • Posts: 43
    • View Profile
Re: Q-Gears.0.09
« Reply #62 on: 2006-12-07 14:52:34 »
Nice work Akari  :-)

einherjar

  • *
  • Posts: 38
    • View Profile
Re: Q-Gears.0.09
« Reply #63 on: 2006-12-10 14:18:44 »
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:



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...
« Last Edit: 2006-12-10 15:53:38 by einherjar »

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: Q-Gears.0.09
« Reply #64 on: 2006-12-10 16:04:43 »
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
Code: [Select]
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

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: Q-Gears.0.09
« Reply #65 on: 2006-12-10 16:32:23 »
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  :|

einherjar

  • *
  • Posts: 38
    • View Profile
Re: Q-Gears.0.09
« Reply #66 on: 2006-12-10 17:28:40 »
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.

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: Q-Gears.0.09
« Reply #67 on: 2006-12-14 10:51:18 »
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.

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: Q-Gears.0.09
« Reply #68 on: 2006-12-18 08:03:03 »
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).

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: Q-Gears.0.10
« Reply #69 on: 2006-12-18 08:25:48 »
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.

einherjar

  • *
  • Posts: 38
    • View Profile
Re: Q-Gears.0.09
« Reply #70 on: 2006-12-18 09:20:51 »
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?
« Last Edit: 2006-12-18 09:27:17 by einherjar »

Akari

  • Moderator
  • *
  • Posts: 766
    • View Profile
Re: Q-Gears.0.09
« Reply #71 on: 2006-12-18 11:29:34 »
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.
« Last Edit: 2006-12-18 11:32:47 by Akari »

einherjar

  • *
  • Posts: 38
    • View Profile
Re: Q-Gears.0.09
« Reply #72 on: 2006-12-18 11:34:58 »
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.

gigaherz

  • *
  • Posts: 105
    • View Profile
    • gigaherz's shitty stuff
Re: Q-Gears.0.10
« Reply #73 on: 2006-12-18 19:31:13 »
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...

einherjar

  • *
  • Posts: 38
    • View Profile
Re: Q-Gears.0.10
« Reply #74 on: 2006-12-18 21:10:20 »
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 ...):

Code: [Select]
== 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):

Code: [Select]
uint8_t cell_data[sizeof_cell];

was replaced by:
Code: [Select]
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.
« Last Edit: 2006-12-18 21:52:04 by einherjar »