Topics

1

Q-Gears / using q-gears for testing team avalanch data?

« on: 2013-04-17 00:44:11 »

It's been a while Akari what do you think of the practicality of doing that?
If one extracts the data ("normal") for FF7  and replaces field backgrounds with new media, what difficulty would it be to use Q-gears to test the new field data?

Unfortunately I've yet to make a working copy, that's not your fault it's the fact my drives are SATA interface with SCSI commands and most OS's don't like that (mutter) for boot up (especially Linux with the complex boot sequence they have now).

Cyb

2

General Discussion / Probably a dumb question but

« on: 2013-02-28 02:18:01 »

A few things

• I still have Jenova Griever Dagger DLL based PS1 editors along with code.
• I may port them to linux and GTK+ based window systems (with same plugin system as before)
• I have a new toy called iso_builder I am working on.

The question ...

WHERE CAN I put discussion for these these here? It's been since 2006 I've worked on the PS1 stuff (computer issues to put it mildly).

However I've finally found the most crazy way to maintain them, it will work (maybe)

I plan to use sourceforge sometime for these
I may attempt to integrate the save game editors into Qgears (even)

Tools states "post no new threads" so ... these are game editors 3 and 1 utlity that may fit under game hacking tool (for chrono cross FF7/8 and 9 for now) iso_build.
iso_build I plan to later (as in months) encompass UDF based ISO images so FF10 and FF12 can also be "modified" as desired.

It's companion tool may be iso extract. The latter is much more complicated than assembling an ISO image and I've yet to figure how to make it work without some intimate knowedge of a disk or data.

Since these are both designed to work WITH a scripting language (IE python bash etc. ) It may be simple to make iso_extract work with these since it is designated to be a comand line tool like iso_build.

iso build is intended to be used with a tool like make (to assemble a new ISO file from a set of data files for example battle models and battle scenes). After said ISO is assembled editing the field bin file should be possible by using ISO extract to find locations within the new ISO file and programatically updating field bin and doing a second iso build to add the replacement file.

Anyhow any idea where I can post announce progress et al for these tools?

Cyb

3

FF7Voice / Cloud lines and other means to an end (suggestion)

« on: 2011-10-17 22:37:02 »

I've noticed the chronic issue of someone acting 1500 voiced lines. Apart from driving the actor insane (take 12 of line 1422 ) and hoarse in voice, it's a bit unrealistic. I concur that the major lines can be voice acted, more accurately put I suggest scenes that require inflection not just casual conversational tone. I would suggest a slightly different approach to the esoteric scenes that aren't required to do anything with much emotion.  Voice synthesis using the actors voice and some slight tuning something like espeak could be used to make esoteric speech (IE stuff that doesn't involve inflection etc.)

I have tested this with the generic MBROLA diphones provided with the program and the results were reasonable, for both male and female gender. I would suggest this as a reasonable means to an end. Especially for the casual conversation in the game.  With some diphonic tweaks you can create a considerably larger set of voiced lines, and reduce the voice actors 'wear'. This is what you have to do in any case (without the addition of speech synthesis), so I see it as a creative means to getting there faster.

There is an incomplete SSML interface on the synthesizer but to key you in IT WORKS, I've USED IT, for a simple project of giving personcom CM partners in Oblivion a somewhat artificial voice instead of a copy of Imperial race voices. Worked surprisingly well that I didn't erase all evidence I tried it. I still use it too. LOL

I wouldn't recommend it if I hadn't tried it already. The Carnegie Mellon speech website is fairly good, that is used by Microsoft (who shamelessly gives no credit to the creators as usual), they just used professional voice actors and tuned things a bit to make the Microsoft speech tools. Also there voice recognition software is a copy of the CMU sphinx tool kit. (blatant again but the licensing allows this). Just tweaked specifically for Microsoft products.  The issue is becoming familiar with the tool. I suggest espeak because it is much simpler to use and fairly straight forward. No need to compile anything for using the synthesis tool.

This would allow a lot of 'blah blah' lines to be generated without having someone speak them, and leave the more important lines to be tweaked and worked on by the voice actor. In addition any 'normal' lines can be generic or voice acted and or tweaked as needed.

Just a thought.

Cyb

4

Q-Gears / current source state? (Akari?)

« on: 2008-08-17 17:37:08 »

I've been cleaning up some of my source that's floating around in my computer and realized I haven't checked out an update on the SVN system for 10 months or more.

So stupid questions time:
Is there any current source in the SVN on source forge at all?
Is there any code plan I can look at?

That's really all.  I'm working on chrono cross stuff at the moment and suddenly wondered about Q-gears code state.  I remember working on compiling OGRE a bit back on this machine.  Sigh I have so many things and I forget which I'm working on (LOL).

Anyhow looks like you are knee deep in the battle scripting system currently.

Cyb

5

Scripting and Reverse Engineering / COP2/GTE in they playstation (usage)

« on: 2008-01-09 02:46:41 »

So the PS1 has a coprocessor called the GTE.  I've been examining it's IS (instruction set for short I hate writing IS 40 times) so here is the question.
According to halkun (TM) direct access to the hardware was verboten. This ment the bios was used for a lot of things.  IE GPU DMA setup etc.
So the dumb question how often were the developer libraries Sony provided used versus some one writing there own engine for passing 3d data to the GTE and out again? I'm curious because I was looking at how complicated using the GTE could be (and to me it seems as though it would be so). Thus my assumption is the game makers used standard sets of code (IE libraries) to handle twiddling there 3d data and sending it to the GPU.  I would if it were fast enough.  Less messing around at least.

Thoughts?

Cyb

6

Q-Gears / Akari Ogre and Q-Gears

« on: 2007-09-30 18:14:34 »

Greetings Akari likely thou art busy (doing school work hopefully).
In any case you mentioned OGRE usage for your last release you will work on of Q-gears?
I've been examining OGRE.  I take it you wish to use OGRE for handling the lighting etc?
I was at one time looking to migrate battle models into GLScene well actually the entire battle scene with the battle models as heirarchical objects within.
In the case of FF7 battle models I created meshes for each sub object etc.  I didn't get around to the animation information.

So what was your plan of action here?

Cyb

7

Scripting and Reverse Engineering / Fractal Interpolation revisited

« on: 2007-09-29 13:30:06 »

The original thread is here
Instead of reopening it, I've spent the last few days reading up on it specifically. (don't ask why)
In any case this URL was very helpful in understanding how it works as well as understanding it's limitations.  The IFS/PIFS systems are useful for enhancing images however, and might be useful in Q-gears. The enhancement is not as good as some people would like on to believe.  Also it does not actually ADD detail. Instead it adds "possible" detail.

Anyhow that FAQ should be very helpful. The algorithm is quite tedious. So expecting speedy enhancement is unrealistic. The interesting thing is FF7's backgrounds are already sorted and broken up into 8x8 blocks so processing them may not be as big of a deal as would be otherwise.

Cyb

8

Q-Gears / PS1ISO Utility <-- find those pesky files!

« on: 2007-05-26 17:41:46 »

Right so what does this do?

It will read an ISO image file and give a nice clean list of the directory structure and disk information.
It will also indicate mode2 mode 1 audio video files that have the odd sector size halkun has been quietly cursing about.
This is displayed in a column called Mode and with a sector size in it.

I am looking for a way too allow people to access it.

Suggestions welcome (opinions heh LOL).

Here is a link to a screen shot.

Cyb

PS

Divshare URL for the installer.  It is rar'd (because exe files aren't allowed ) with the executable installer in it.  This will install 3 files 2 DLL type files and one executable.

9

Q-Gears / New ISO image access routines + Other

« on: 2007-02-22 01:08:13 »

I've been working on these for a while.
Some notes. ISO directories are sector sized and sequentially stored. However they do not overlap sector boundries. This makes for getting the contents confusing if you aren't paying attention.  A directory size will ALWAYS be a multiple of the size of a Mode1 Form1 sector (2048 bytes).  The size of files in IS9660 reflects the size in sectors * 2048 used for Mode 2 files.  This of course means that the actual size is... relative. Furthermore a Mode2 file is never 2048 bytes in size.  (read never several times) Why is that?  Mode 2 files have subheaders which need to be read in order to know what the data is.  8 bytes are used in this subheader (actually only 4 but they are repeated againm likely to ensure that the data is read correctly).

Currently my routines are not perfect (no doh). They will only read a data sector at a time.  I will make them set up to read exactly how much data from a set of sectors you wish to read from, however, you need to be wary of the fact mode 2 sectors may return more than you bargined for (IE more than 2048 bytes per sector).   It might be good to differentiate between these special sectors by returning Sector Size for the beginning record of a file.  You can read 4096 bytes from a Mode2 file but not read a complete 2 sectors.  The size varies per sector in the file also.  Some of the movie files in FF7 are 2K sectors some aren't. The movies with audio are not and they vary throughout the file, audio is interleaved with the video sectors.

So what works? Searching for a file and finding it's directory Record information works.  Soonish I'll have the special 'file system' set up by Akari functioning with ISO images of the 2352 size per sector variety.

The other thing is .. start up file system etc.  I think it would be sane to have this a CLI option for Q-gears (and or in an XML based INI file).   The file system should be just fine.  I think in the current testing however we might have a few issues.

So should I dump the complete listing of Directory/Files and the Logical sector numbers for FF7 disk 1 so we can examine FF7's engine for sector and offset information (IE it assumes something is in a certain place instead of looking for a file).

Of note the PS1's limitation on CDROM directories appears to be 2 directory sectors. Any mroe than just 2 sectors and the PS1's normal CDROM routines loose the rest of the directory (it likely has a permanent 4K buffer to iterate through).

Cyb

10

Scripting and Reverse Engineering / FIELD.BIN (exploration) thread

« on: 2007-02-20 02:07:55 »

The complete list of field locations (ONLY) is contained starting @ 0003A5B8 of the uncompressed data.  This is the LSN and size of each file IN field.bin
0003A5B8 to 0003EF80 2 pairs of uint32 (little endian) Logical Sector Number then Size.  Again Field files ONLY (this does not include BCX files in other words).  2361 files total for that.   0003F08C to 0003F0DC has the BCX files indexed.
I haven't found anything else YET but that's what this thread is for what's where in it.
Anyhow looks as though the game uses this index for loading field files (Akari keep that in mind ).

Cyb

Edit 2/21/2007
FIELD.BIN is located at sector 55000 it's the first record in the \FIELD directory.
The first file listed in FIELD.BIN at offset 003A5B8 is DUMMY.DAT.  The ordering of the files are thus DAT MIM then BSX.  I'm not sure if this is related to the PC's ordering of the data for each field location (7 sections in the DAT + section 8 being the actual field data and section 9 being the BSX field character data or something like that).  The final entry at 003EF78 is ZTRUCK.BSX. So this table covers JUST the field location files.   The section from 003F08C to 003F0DC are the BCX files + the FIELD.TDB file (Texture data). This leaves 2 files not index and those are DSCHANGE.X and ENDING.X.

There are a number of uint32 numbers within the FIELD.BIN file that are suspicous when read in HEX. They appear to be offsets in the playstations memory.  In addition the entire list of Opcodes are contained much like what was in the PC executable.  To get to the point FIELD.BIN is likely the FIELD engine program that is loaded on top of the kernel.  When porting the merged the FIELD engine section and KERNEL section into one ... conglomerate.

11

Q-Gears / Micky's code and FF7 text conversion (small discussion time?)

« on: 2007-02-08 19:46:20 »

All right, there are a few burning 'issues' with the text in the system.
First we don't really need to convert the FF7 text to ascii (just the other way around) however this is not a good idea to convert FF7 just to ascii (my view).
I believe what is needed is unicode to FF7 text conversion instead.
Reasons?
1) this expands the number of symbols that can be used in the engine to an international set of symbols for testing or what have you
2) it will help debug (debunk) the proper Kanji Katakana Hiragana etc. symbols used

We want SYMETRICAL functions for this.   That is we should be able to take Unicode and make an FF7 string, then take an FF7 string and make Unicode output.  For the actual engine this is not particularly useful generating unicode symbols from FF7 text that is.  The former is useful for handling XML data to be inserted into the engine for debugging.  However generating unicode to some sort of debugging console I think is useful for finding out the Japanese encoding.  Anything the FF7 to unicode function cannot translate should be hexencode like Postscript (IE 0xEA, 0x02 is emitted "<EA02>").

Since I do not have the Japanese Version of FF7 (or International version), this makes for a few problems for me, I am not able to do any of the symbology matching with the code set. I'm fairly certain the US version and the Japanese version have a similiar set of symbols, the US version likely just has the 2 byte prefix symbols removed for the Katakana Hiragana and Kanji symbols.  Micky made a table to convert FF7 code to Unicode, I'm not sure if this is a full symbol set (all 256 base codes).  I don't think it covers the prefix symbols for multibyte encoded symbols (like Japanese symbols would be).  If it covers the full 256 symbol set, then running FF7 Japanese will require the engine to actually know it's running the Japanese version (which to be blunt would suck because I would rather the engine be version agnostic for that).

This really only applies for debugging dialog output.

Now what to call this function.
FF7TextToDebug?
FF7TextToUnicode?
For debug output it would be good for specialized text for cloud tifa cid etc output (party1 party2 party3) color indicators etc. so that there is some sense to what someone is looking at.  For converting to just unicode I suppose that hexcode output will work (IE <B2> <B3> <D2> instead of {DialogBegin} {DialogEnd} {Grey}).

Do we need 2 functions (debug and unicode output) or just one with a flag of the type of output?
FF7TextToUnicode(void *FF7Text, int Conversion)
where conversion is
FF7None {any symbols that cannot convert to unicode are ignored}
FF7Unicode {any symbols that connot convert to unicode are in HEX format}
FF7Debug {any symbols that cannot convert to unicode are in detailed debug format}

Before the going with this dicusion becomes weird I am reading this FAQ about unicode and Linux, obviously we want to make this code more universal than would be otherwise using windows specific code.
For UTF8 enoding I don't think this will be too big an issue since most of the symbols in FF7 fit within the UCS encoding ranges (maybe even Circle Square Triangle X too ).

Anyhow this is something that likely needs to be done. As far as I know there are only 3 official translations. Europe, US, and Japan? Unless Europe had further subdivided versions? I can't seem to find a list of the number of offical translations.  So if anyone knows what languages it was officially translated into, I would be glad to here about this.

Cyb

12

Troubleshooting / For PS1 FF7/FF8 only these are old but still functional

« on: 2007-01-23 22:17:20 »

Right so what am I talking about? What's old and functional?
With Qhimms original data structures and slow and stteady progress over the eons of seconds.  These are hardly finished.
Both GrieverFF8 and JenovaFF7 plugins have bugs some are not so easy to find.

DLLEdit works fine. Be sure the files are in the right locations. These will allow you to pimp your party big time.  IE cloud with minimum level and killer strength etc. Get all the cards (if you want them that is) I'm looking for card quest bits right now myself. I think there are a few of them.  I've decoded more of the game bits in FF8   The FF7 Jenova toy you need to use carefully because I made more additions and the chocobo stables et al aren't perfect. Don't mess with more than 4 let me put it this way.  The custom button changing code is not done either.  It's there. The window background stuff works fine though.

So what's missing? Foreign game version support. It would be great if I could get the FF7 Japanese font encoding and it will work with the Japanese PS1 version.  Unfortunately I can't support the PC versions of these games, I would need the PC save information (well some of it) and add the location etc information into DLLEdit.

Get it Play with it here.

Some day Dagger and Xeno will be done (save game editors for those games).

Cyb

PS thanks for those who gave clues to this guy to make it work

PPS if you do find bugs in the plugins let me know.
Obviously if there are some details of the save file image I don't have that's not a bug (it's a feature waiting to happen ).

13

Q-Gears / Battle script (SCENE.BIN) + more

« on: 2007-01-17 18:38:09 »

Right so I was wandering through the wiki (examining the data on SCENE.BIN) and wondered about the battle scripting and discovered a nice add link for it.  Is this the same code format as the regular field script or is it an entirely different beast? I suspect the later however I could be wrong.  I am pretty sure that the script has things such as dialog etc.  (well duh anyhow).
SCENE.BIN is very interesting so I'm studying.  I my as well start work on the battle part of the engine (it's what I'm most familiar with in any case).
So .. summary
scripting for battles? Is it the same as the rest of the engine or different? What about dialog in battles? Opcodes?

Also it's been batted around a lot, the scripting system in general is the next quesiton (Querry?)

There appear to be 2 ways to really go with it.
The first is psuedo functional language with proper clauses etc for instituting neatness. This would make it look more like PASCAL or C in terms of appearance (TCL perhaps). 

The second is go with the code. IE just use the current opcode names and make it more of an ASSEMBLER level scripting support than anything.  I suggest the very least is to bracket an entire script with BEGINP and ENDP if this is the route.  This helps to organize things visually at the very least.  I'm speaking from a script dump point of view.  This is obviously easiest to do.

One issue is that the scripts operate in paraellel, so do we understand how this works.  I remember talking about it is all.  Nothing is in the wiki so I must assume we never concluded much.

As for events in the field script I have some thoughts.  The first one is by default the initiation script for all field entities.  So I recomend this event be called, Start or Init.  Even though it's called regularly I think.  Do scripts get run periodically and if so how are they queued for periodic (IE timed) execution?  The animation in  field locations I suspect are controled by this correct? (IE a script runs the animation and can turn it on or off etc.)

Cyb

14

Q-Gears / The Wiki Additions thread

« on: 2007-01-12 19:28:59 »

Right so I've been secretly adding things to the wiki for a while now.
However I realized this might not be as helpful a thing as I thought.
Something like someone goes to add something and find someone has added and revised it 10 times then feels a bit confused.

So when I actually ADD something to the wiki I'll add it to this thread, feel free to do the same ye who enter data in the wiki!

Modified and cleaned up some of the field descriptions.
Cleaned up a number of other things.
Added TDB file description, these are the textures used in the field files.
Pretty mindless work but done none the less.

15

Q-Gears / Back to the ISO system

« on: 2006-12-29 19:22:12 »

All right I have a few hours to work on this at my will so a few questions

1) Is autoconfig working? IE can I do ./configure and let Q-gears compile happily?

2) For autoconfig I will be ADDING code, so what do I need to do to make things compile happily and without much duress?
(I recomend giving a website with Autoconfig config et al for dummies and then a more detailed site.  As likely I will want to do a test of adding a file to the source and then incrementally add them).

The ISO FS code has been done for a while, I just never kept up with the constant flux of changes nor could I get Q-gears to natively compile on my developement machine.  Therefore tips on integrating the code and or making it work would be muchly appreciated.

3) Is anyone working on the battle model/engine? I have put some information on the PS1 models up.  However the animation format is the Achiles heel of all my work.  I know it was deciphered a while back.   I'm just wondering if any has bothered to put it in the ussual repository or if someone (IE me) will have to work through it and put it in the repository.

4) I'll be working on the PS1 FF8 image file information.  Since I have the ISO9660 information well ingrained into my head this shouldn't take too long. The background format will be a bit fun I suspect.  I already partly understand the battle and field model format used as well.  Ahem.

5) Do we need any specific documentation made for Q-gears. It appears we have volumes of source code but the documentation I canna find

The Q-gears Logo project is a work in progress as well.

See I'm doing things, just not what I expected too!

Cyb - (life is a series of deviations on our deviations from our deviation from the main point... which might be a deviation as well)

16

Q-Gears / Warning Code comments ;)

« on: 2006-12-12 04:08:27 »

Ok I'm going to be going through some code and adding a bit of  commenting for doxygen.
Also converting prodigious use of constants into named explicite constants.

One simple question though, do we use a macro constant or an actual const.
IE

Code: [Select]

#define HOLY_MACRO_BATMAN 42f
versus

Code: [Select]

const float holy_macro_batman = 42f;

Also if a constant is only used in one area of the source code, say for example battle models. I suppose a globalized style declaration is a waste of time (or typing).
local
Ex:

Code: [Select]

const u32 l_number_of_bones = 0;
versus
globalized

Code: [Select]

const u32 ps1_ff7_number_of_bones = 0;

I prefer Macro's for MOST constants, save 1 type.  Anything that's used in a numerical expression in particular calculations, I prefer typed constants, to get explicite exceptions with any weird coding bugs that may crop up.

Cyb

17

Scripting and Reverse Engineering / Returning to FF8 savestates (Woo hoo as some would say)

« on: 2006-11-10 15:22:02 »

Greetings it's been a while since I've worked on FF8's save state information.
So Here is my current information reguarding the information bits in the save state
These bits are located at offset 0xEA3 (woo?)
My bit numbering convention is lsb to MSB and divide by 8 for the offset into a bit field.
(Address = 61/8 (7) bit = 61 & 7 = 5 Mask = 1 << 5)
Right so here is my most recent List of bits

• Was at Balamb Garden
• Was at Dollet
• ?
• ?
• ?
• ?
• ?
• ?
• 1?
• ?
• ?
• ?
• ?
• ?
• ?
• ?
• 2?
• ?
• ?
• ?
• ?
• ?
• ?
• ?
• 3 Was At Dollet Comm Tower
• ?
• ?
• ?
• ?
• ?
• ?
• ?
• 4?
• ?
• ?
• ?
• ?
• ?
• ?
• ?
• 5?
• ?
• ?
• ?
• ?
• Scolded During Seed Exam
• Met Quistis At Balamb Garden Gate
• Ran into Someone during Seed Exam
• 6 Met Selphie in Seed Exam
• ?
• ?
• ?
• ?
• ?
• ?
• ?
• 7?
• ?
• ?
• Seed Exam Report
• ?
• ?
• Basic GF Junctioning Tutorial
• Magic Junctioning Tutorial
• 8 Elemental Attack/Denfense Tutorial
• ?
• Caring for a GF Tutorial
• Renzokuken Limit Break Tutorial
• Zell's Limit Break Tutorial
• Rinoa/Angelo Limit Break Tutorial
• ?
• ?

Additional place information in the location field of the save file description
(unsigned 16 bit int @ 0x184)

• 99 Dollet- Comm Tower
• 103 Timber- Forest Owl's Base
• 130 Deling City- Hotel
• 132 Deling City- Gateway

I'll add 'bits' as I go over the game play again.

Cyb

18

Q-Gears / Eclipse (getting it)

« on: 2006-08-07 15:45:45 »

In case someone might be interested in getting eclipse
Here is the general download page
You need
Sun JRE
Sun's JRE download spot
too run it
Eclipse Distribution
torrents: Ibiblio torrents
Straight download
Currently I'm reinstalling just to get rid of a few nasty errors (can you survive a $#@$ upgrade?) LOL


Cyb

19

Q-Gears / Disorganization incarnate <source Q-gears direction and wot's up?> Debugging

« on: 2006-08-05 19:44:37 »

Much silence apart from porting.  However I will be testing the ISO code this day.  I need to make more ISO files too. Ahem.
The ISO code will make Linux testing and coding easier. <-- simple idea at least.
However do we have a debugging step by step system for game starting etc. ?
I think the state of things is great but we might want to focus on stepping through bits of the script with the engine.
We do have a script dumper which will help facilitate this, and inspite of it being incomplete, it's still useful.
So Q-gears debugging console is my next proposed step.  An IDE would be nice however I'm slightly confused (confuzled?) as to wher eto start with a GUI variant so a nice window with a console will be the first animal. Also the debugging I proprose should use a SOCKET. This makes the debugging program seperate from the primary program.
My proposed system is simple.
 q-gears --debug (-D) on the command line sets q-gears to switch on debugging for the game.
 --debug=##### sets the port default port should be 19974 (release date of FF7 and random month?)
 in addition the debug switch can have an option to break at the first point of script execution when the engine loads the game.
Proposed command structure
Each command is terminated by a carriage return <CR> line feeds are ignored (IE <CR><LF> pair the system will only respond to the <CR> and the <LF> will be striped).
S<CR> single step perform 1 opcode and stop
S###<CR> step multiple times (###)
Both of these instructions execute all running scripts one step.
D? <CR> dump  Complex command dumps hex data by default from a specified location.  Addressing system etc. needs to be worked on.
 Should be able to dump
 STACK
 VARIABLES <temporary>
 GAME VARIABLES <all types and sizes>
 ENTITY and ENTITY state
 SCRIPT STATE
W?<CR> write to an address some data.
B?<CR> break point manipulation
R<CR> reset the engine (IE game engine reboot)

In any case addresses Data etc. Should be in HEX format.  Dumping is much the same.

The idea is to have an external program handle the debugging.  This will allow for example Q-gears to run on one machine and the debugger another (display wise much simpler in my view).
Since the debugger information will be game specific, I recomend storing the variables, descriptions of the variables, opcode and decoding information reguarding them be stored in external XML based files. This makes it easier to create new 'templates' for more game engines as they are added to Q-gears.

Cyb - now testing ISO code.

20

General Discussion / Square News

« on: 2006-07-13 15:55:30 »

Found this article floating on the net.
It doesn't sound to encouraging considering squares game quality has been ... not as good in the last few years.

21

Q-Gears / The 'Why' Eclipse thread

« on: 2006-05-21 22:39:45 »

I mentioned this a while ago, and I suppose I'll mention it again, I believe it might be wise choice to use Eclipse for the IDE in this project.

Upside
1) It operates/supports multiple platforms.  IE Windows MAC Linux SunSparc Cray3... etc.
2) It can (if you so choose) manage the makefile for us IE set the makefile up without getting ourselves involved in mangleing it all the time (halkun would probably appreciate this feature the most )
3) You can update the IDE from the IDE, with that handy Help->Software Updates feature!
4) Automatic compile when you save ( see your screwups RIGHT AWAY! ), and other helpful program assistance (structure completion etc)
5) plugins, if we need some tool to help developement, Eclipse can do it.  IE new content compilation etc.  So if we want to play the "ADD" things for game usage we can still use the SAME IDE with new plugins.  It can support multiple languages (Java Python C C++ are some of the current ones it supports in the editor). 
6) relatively painless too install (this was my biggest surprise under Linux).
7) Integrates into GDB for debugging purposes (requires the plugin of course).
Integrates into GCC for compiling with options for target though I am trying to see how much control there really is.  I know the SDK for Palm nukes your x86 gcc tool chains under windows but this might be a 'palm'ism.

Downside
1) It's not small.  It's a few megs to download the basic package however to get the CDT etc.  It takes a while to get it all installed.
2) It's not fast. It's a Java application as it was originally written in Java for developing Java applications. Under linux it's a bit pokey, it's hardly noticeable under windows to be honest.
3) It doesn't have a subversion plugin yet 
4) It takes getting use to and isn't {insert name}'s favorite rubber ducky.   
5) Palm SDK and multiple platform tool chains are still in the works.  That is switching between compiling for windows linux or a palm from the same IDE is not as simple as changing the target.  This is about the worst problem I can think of! 
6) For C++ it doesn't have a handy reference for various common objects templates and functions in C++ or C, I don't know if this can be added since Eclipse orientation appears to be narcicistic 

Anyhow... to promote maintainability and make things kind of sort of the same.. that's my suggestion.

Cyb

22

Q-Gears / Subversion and that initial Checkout

« on: 2006-05-21 04:20:22 »

Ok I got the bloody thing to compile eventually (mutter) however I do have a small problem
First Sourceforge tells me to use this to get Q-Gears
svn co https://svn.sourceforge.net/svnroot/q-gears
Erk!
svn: SSL is not supported
The only problem is Sourceforge doesn't use SSL here.. OK
now I try this
svn co http://svn.sourceforge.net/svnroot/q-gears q-gears
Which returns..
svn: PROPFIND request failed on '/svnroot/q-gears'
svn: PROPFIND of '/svnroot/q-gears': 301 Moved Permanently (http://svn.sourceforge.net) q-gears

All right some clear information for the just playing with SVN might be good now
svn co http://svn.sourceforge.net/q-gears doesn't do a whole lot either LOL.

So I would like to see what we are doing to check things out.. because
1) my windows box died again (I think it's the MB killing my hard disks  ).
2) I throught at first I miscompiled subversion.. brain must engage
3) using the exact commands given by sourceforge doesn't work... so it might be good to be sure everyone knows.. (I guess)
4) Yes I did read how to get subversion from the book.

I can't see what I was doing wrong.. so it's probably something so simple it's ludicris

Cyb

23

Q-Gears / File System discussion

« on: 2006-05-13 19:21:27 »

I'm looking at the code that's been commited ...
I'm uncertain where to insert the ISO file code...
clue me in here
I found some commented code though!

1) do we create a ISO9660FileSystem.(h, cpp) file(s)?
2) how does this 'link' in with the main code?
3) I don't believe I will be able to compile this (though I'll try the linux variant first I guess).
4) ISO.cpp is in Kernel/Filesystem... It should be in src/Kernel/Filesystem right? So this needs changed... or are we thinking src/filesystem/ISO/?

Comments
Readme's for each directory so people aren't apt to put thinggs where they don't belong.. or a FileOrg Readme.txt file... <I think you get the idea>
Comments at the begining of a file describing
Where it belongs in the big scheme of things
What it does
Change log information for the file

perhaps we should use Doxygen for making help information from comments?  This will force commenting and fast help information for new contributers.

Anyhow.. does anyone KNOW where to put the ISO code? It's not apparent to me where it belongs at the moment.
Second do I need to create a new file in filesystem or in driver to use the ISO Image functions.
Third what naming convention are we going to use for the new object?
Fourthly are there compilor switchs that need to be defined to use a particular FS type?

Cyb

24

Q-Gears / Unit Testing | Code/Peer Review | Coding rules

« on: 2006-05-12 05:25:19 »

Ok I would prefer to have small pragrams (apart from the main program) to unit test with.
Should these be collected in a directory called 'test'? or something akin to that?

What I'm getting at is
make test
<much compiling>
ISO test
<various test information displaced>
ISO FS test
<more test information about reading file data and reading file sizes etc>
These can return information that can cause make test to fail (which is a good idea)
Also it allows each unit section to be tested when someone changes something to be sure it works acording to spec.

This is how I discovered a bug in my ISO structure information under Linux I'm not sure if it does the same thing under windows or not.
I'm trying to comply with some sort of 'standard' we need too use throughout the coding process to test things.  It may seem picky but I've attempted to wade through bugs before and it's best to test everything that needs testing in each unit so the bug is swated before a bug becomes an unfindable flaw.

The next thing is Peer Code Review of the code.

This has saved my backside.. and I think we do need it. (See i++/++i and vector class discussion).
When it comes to STL I'm weak. I predate STL (period) so I will have to learn it now I suppose (mutter)
In fact I predate Template usage in C++

That being said.. we should be careful with C++ constructors and destructors as well as inheiritance usage.
Porting to certain platforms will be made impossible if you rely on any static objects and the compilor to create them in some sane sequence.
(Palm OS is one such animal for example).
This again is why Peer review might be valuable.  It's not about trust it's more about making sure the code works without later major revisions on several platforms.  Obviously PC's will be the first platforms to run it, (Linux Windows et al).  Even porting to winCE make require some important changes. It's best not to paint ourselves into the proverbial corner and have to tear out the floor.

Cyb

25

General Discussion / MySQL data base issues

« on: 2006-04-30 21:32:54 »

Hey ya Qhimm if you can read this you are more fortunate than I.

It looks like either someone is trashing your database server or it's having issues with staying up.
On the forums and the wiki I've been recieving database errors from loosing connection to not being there the last 3 days. The forums PHP software appears to be running just getting errors from the MySQL server for your SEQUEL database containing the wiki and the forums.  

Thought you might be unaware of it.  

Cyb

PS: How are things anyhow?