Messages

676

Q-Gears / Re: How about OGRE3D?

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

Nothing is easy bottom line.  Why am I saying this? Because I've tried it with GLscene and it wasn't a simple matter to convert the format to anything else.

If you want to knew - OGRE support opengl-like polygon creation (begin, end, vertex, color and so on) and can internally convert all of this to inner format - very easy, you know =)
By the way. Our engine will use inner format too. There are no way to handle this without specific format, and I'm sure that our format will be worse than prophessional. There are a lot of people who work and test it for a long time. We just dont has resource to do things that way =)

677

Scripting and Reverse Engineering / Re: Sprites in FFT

« on: 2006-05-24 19:01:13 »

The engine is very similar. Sound format are exactly the same, 3d formats looks similar to one in Xenogears. This two games was developed paralelly by different teams, but I think engine of FFT is slight earlier than Xenogears. Maybe Xenogears was started when tactics was near half-complete, so they use basic engine and modify them a little.

678

Scripting and Reverse Engineering / Sprites in FFT

« on: 2006-05-23 19:41:57 »

It's a long long time since last I reverse something =) It's nostalgic.

I try to understand how sprites in FFT works because sprite system is similar to one in Xenogears.
The real images are in SPR files. The Frames data are in SHP files. I still cant found size of single tile, but already have some result

The image itself:



And the whole frame




The image that consist from one tile looks normal, but on the first one has many garbage because of wrong tile size. (I set them manually to 48x54)

679

Q-Gears / Re: File System discussion

« on: 2006-05-22 21:51:05 »

Progress:
Nearly done setting up ISOfilesystem[h/cpp]
Added ISOFile.[h/cpp] this contains the ISO file system access functions that ISOFileDriver uses.

removed isofilestream.[h/cpp] and other files not really needed anymore.

You need to pass ISOFileDriver a path to the ISO image currently (it handles the rest).

I'll need to figure out how to test it with the current set of functions.
Akari?

Cyb

could you upload them to SVN?

mFileDriver.GetFileSize(path) and mFileDriver.ReadFile(path, buffer, start, length)
must be working correctly. If they are - everything else would.

680

Q-Gears / Re: Todo list

« on: 2006-05-22 10:28:27 »

Halkun, what shall we do next? There are a lot of posibilities, but I think we need to do something that can be displayed on the screen... fonts and windows for example.
I already create Tim loader... so create font must be easy.

681

Q-Gears / Re: How about OGRE3D?

« on: 2006-05-22 02:48:47 »

What do you mean that it would be hard? You can use glOrtho for the field, and then use your standard drawing for the models.

Or, push a new projection matrix on the stack and then pop it when you want the models.

I mean it's not plug and play.  More importantly with just GL (if you read carefully) it's easy.  With an engine, it's not so easy.

It's easy. People use engines not to make things harder, but otherwise to make it easier. We need a lot of things that we need to write by ourself aside of GL. Frame limit is one of things thet needs to be created. Console for runtime script debugging, All shading and camera work.
The most hardest are all video cards support. We need a lot of hacks to make them all works correctly and fast, there are a lot of bugs. Engine solve all this problems.
In addition Ogre can use DirectX render which is faster under windows.

Now the thing is that you have 2d layers and a walk mesh.  Somewhere in the field file information is what describes the placement of the 2d layers relative to the walkmesh and when what gets drawn.

In summary you have a number of layers, PC and NPC model information to analyze before anything gets drawn.  The ordering of the drawing changes depending on where the PC/NPC is on the walkmesh, and the positioning of the 2d layers. This is not easy especially in a large scene with a bunch of NPC's. If it were one could just throw it together in a few minutes

2d enviroment is not a problem =)
Read the manual to Ogre =) More importantly that 2d and 3d already works correctly and tested by many users. If we use our own render it will be a lot of bugs. There are to small amount of developers to work on all this things. We need to concentrate on the game itself, not on the one of the hardest things - 3d engine.

It's not problem with ether engine or my abstraction from open gl (the model is loaded into inner format and then we works whith it as one). On lower level they do the same things.

682

Q-Gears / How about OGRE3D?

« on: 2006-05-20 20:37:04 »

OGRE (Object-Oriented Graphics Rendering Engine) cross-platform 3D engine written in C++

http://www.ogre3d.org/

It may be good idea to switch to this graphic engine because it already implement features that we need to do anyway, such as camera and particle. I dont think I can handle all 3d work as I'm really not good at it. This engine was written by professionals and many real game use it. We have great posibilities if we use it =)

683

Q-Gears / Re: That #@&!! linux segfault is still there ;_;

« on: 2006-05-20 20:29:57 »

I add "assert(file != NULL);".
This will terminate application as soon as it find this =)
I don't know if this is good idea, maybe it's better to throw exeption....  But it needs to be handled somewhere later.

684

Q-Gears / Re: Does anyone know how set struct aligment to 1 byte in Dev-C++?

« on: 2006-05-18 02:42:59 »

Had this problem with sizeof() giving incorrect size of structures.

Code: [Select]

#pragma pack(1)
..fixed it.

Thanks, it helps.

Isn't it faster to align 32-bit though?

This is needed for writing binary files to disk. Save screenshot for example =)

685

Q-Gears / Does anyone know how set struct aligment to 1 byte in Dev-C++?

« on: 2006-05-17 17:59:09 »

subj.

686

Q-Gears / Re: File System discussion

« on: 2006-05-14 15:23:07 »

1) do we create a ISO9660FileSystem.(h, cpp) file(s)?

Nope

2) how does this 'link' in with the main code?

Don't try to link with the main code yet, just add Driver class and make sure it works correctly.

3) I don't believe I will be able to compile this (though I'll try the linux variant first I guess).

Why? I think it's not that hard. I can fix some compilation errors on windows, but I dont has Linux so you must do it yourself 

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/?

This should be in src/filesystem/driver/iso/
Always use lowercase names, just for equal name style =)

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.

I'm bat at writing documentation. Maybe Halkun can do this.
Doxygen is good thing!
Change Log can be generated automaticly from SVN update comments.

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?

You should write driver isofiledriver.cpp/h and place it in src/filesystem/driver
All support files place in src/filesystem/driver/iso

I think we don't need any compilator defines for selection of FS, it will be good if application will support different image formats without recompilation. For time beeing we just will work with ISO. Maybe when we have some results we add more CD image formats.

As for coding styles - I like this http://www.possibility.com/Cpp/CppCodingStandard.html
This is standart that we use in our company, so I getting used to it =)
Maybe we will use it? It's simple and easy to use and understand.

687

Q-Gears / Re: That #@&!! linux segfault is still there ;_;

« on: 2006-05-13 06:09:32 »

Then we just have easy error in

void
ScreenDisplayTest::Draw()
{
    DISPLAY->SetPointSize(3);
    DISPLAY->DrawPoints(mPoints);
    DISPLAY->SetLineWidth(1);
    DISPLAY->DrawLines(mPoints);

    DISPLAY->PushMatrix();
    DISPLAY->RotateX(mRotation);
    DISPLAY->DrawTotalGeometry(mPyramid);
    DISPLAY->PopMatrix();
    ++mRotation;

    DISPLAY->TextureTranslate(0.01f, 0.0f);
    DISPLAY->SetTexture(mTexId);
    DISPLAY->DrawQuads(mQuadsTex);
    DISPLAY->UnsetTexture();
}

I has the same error but I fix it for me, as I see not compleatly. Try to comment some of rows in this method in DisplayTest.cpp

I has error here, check this first.
    DISPLAY->PushMatrix();
    DISPLAY->RotateX(mRotation);
    DISPLAY->DrawTotalGeometry(mPyramid);
    DISPLAY->PopMatrix();
    ++mRotation;

Just as I thought its not a matter of ScreenManager after all.

688

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

« on: 2006-05-12 18:44:55 »

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?

It's good idea, but do we really need each test? I think we need to add debug info in q-gears, so we will not met situation like halkun's segfault ever again.

This has saved my backside.. and I think we do need it. (See i++/++i and vector class discussion).

This is not a matter of style. It's matter of effectiv usement of C++
please read books of Herb Satter and Scott Mayers (you could easyly found them in the internet). They talk a lot about optimisation and effective C++ programming.

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.

I want to try port our engine to PSP =)
Gladly they have STL and OpenGL, so we can make it =)

689

Q-Gears / Re: Todo list

« on: 2006-05-12 17:08:00 »

3) We need to create disk or image driver. I create NullFileDriver class, it needs to be replaced with appropriate image fole driver.

Hi, I'm not sure what do you mean by 'driver' but I have one C++ class created that works well for file reading or writing, you can select whether you want to read the file from disk or memory. It can be also easily extended to other sources. Class also supports reading of integers and floats independently of platform ( motorla or intel hardware ). Should I show you the code ?

Driver is my own name for class that lies between real data (ISO) and data that extracted from real files (files on the ISO). There are could be many names, but I call it IsoFileDriver.

Of cource you should =)
Maybe we steal something usefull from there =)

690

Q-Gears / Re: That #@&!! linux segfault is still there ;_;

« on: 2006-05-12 16:59:43 »

Halkun, try this.
http://server.titansoft.ru/akari/screenmanager.cpp
and check log file after executing.

Can someone tell me why a simple opengl double-buffer isn't good enough?

We use simple opengl double-buffer. We just incapsulate it into Display class. If you check functions content - there are usual glDrawArrays in there =)

691

Q-Gears / Re: That #@&!! linux segfault is still there ;_;

« on: 2006-05-11 07:50:47 »

Akari ++i is a possible source of VERY bad things.
What will happen is I will reach mScreensToDelete.size() and I'm POSITIVE that will be a problem
Actually this whole bit of code doesn't look right.
I would check the behavior when you delete a screen in mScreensToDelete.
Generally what will happen here (and you should NEVER use a function for the termination this way really), is as it shrinks and I grows you'll end up reaching a point you are deleting things off in Limbo. (another likely source of the error).

A potentially safe way to do this ( it also eliminates an integer variable )
while(mScreensToDelete.size() > 0)
{
  delete mScreensToDelete[0];
}
That should delete the first element and shift all the screens unless mScreensToDelete is a semi static array that does not automatically shift everything down one position.  At the very least change ++i (which is a preincrement and in this case a definate source for errors) to i++

If this doesn't help.. well DANG! 

Cyb

There is three recomended way to handles vector
1) for (int i = 0; i < mScreens.size(); ++i) - array like
2) for (std::vector<Screen*>::iterator i = mScreens.begin(); i != mScreens.end(); ++i) - through iterators (safe way to all standart containers)
3) using algoritms, for example for_each(InputIterator first,InputIterator last, UnaryFunction f);

This won't do anything, just delete first pointer BUT doesn't remove element from std::vector
while(mScreensToDelete.size() > 0)
{
  delete mScreensToDelete[0];
}
Read standart library documentation after all!!!

mScreensToDelete.clear(); - is the fastest way to clear vector.

++i and i++ are identical in this case, only difference is i++ creates temporary object and then deletes it but ++i does not. Why do you need temporary object???


First of all read this http://www.sgi.com/tech/stl/
This is vector docs http://www.sgi.com/tech/stl/Vector.html

692

Q-Gears / Re: That #@&!! linux segfault is still there ;_;

« on: 2006-05-10 16:51:14 »

Mind you I'm using the default DRI mesa, which is not thread safe. Is this an issue? What pointers can you give me to track down why (*i) is going into la-la-land after the splash screen is cleared?

I dont think that this is a reason, because we use single thread right now.
Try check if (*i) is NULL. If this is a reason (this is the most possible way) then we must understand where it set to NULL.

How Screen classes work.

First, when we create ScreenManager object constructor add SplashScreen to vector of Screens

    ScreenSplash* screen = new ScreenSplash();
    PushScreen(screen);

This vector is drawing correctly

Next thing happens after we press space. In the input method of SplashScreen we asq screen manager to delete SplashScreen and add new Screen.

            SCREENMAN->PopTopScreen();
            ScreenDisplayTest* screen = new ScreenDisplayTest();
            SCREENMAN->PushScreen(screen);

I dont see any errors here. Pointer to screen just added to vector. It must be creared otherwise it crushed.
PopTopScreen add pointer of SplashScreen to mScreensToDelete vector - vector of screens that should be deleted at the next Update of screenmanager. It also remove pointer from usual screens vector. (Posible error - mScreens.pop_back() doesn't remove pointer)

    if (mScreens.size() > 0)
    {
        mScreensToDelete.push_back(mScreens[mScreens.size() - 1]);
        mScreens.pop_back();
    }

At the Update we jusr delete all pointers and clear the vector of screens that should be deleted.

    for (int i = 0; i < mScreensToDelete.size(); ++i)
    {
        delete mScreensToDelete;
    }
    mScreensToDelete.clear();

Thats all. I see only one posible error here, but still don't know why this happened.

Also, could you put the increment operater after the variable if it's not critical to have? That just looks wierd.

I can't and there is reason. postfix increment and decrement orerators create temporary object that should be returned, but prefix operators not, so we all must use prefix operators if there is no reason. Look for example this http://www.devx.com/tips/Tip/12634, this is the first article that I found in google.

693

Q-Gears / Re: About defines and platform specific.

« on: 2006-05-10 16:30:27 »

Why not use STL? There is no need to reinvent the wheel here. And of course Microsoft would say that.

STL is Standart Template Library and of cource we use it. It's the only way to write platform independent code.

You coud look at source and make sure of it. There are std::vectors and some other stl things in there =)

I started out using main() on Mac OS X and got it to compile, but when I tried to run it, it crashed and burned.  After doing some quick searching on the net, one option was to use SDL_main instead.  After I switched it to that, everything seemed to work.

Try to debug it and understand where it crushed. Maybe it's just bug and we need to fix it =)
I see many platform independent application that has Mac support and they doesn't use SDL_main, just usual main.

694

Q-Gears / Re: Todo list

« on: 2006-05-10 16:25:09 »

All right.. (rubs bruised head)

I can add these primitives that can load constant named files.
However don't expect them to work like windows system functions would (warning).
The files are in ISO format and what you normally read in terms of directory information is a Windowized version of the ISO file names on a windows machine under Linux they are fortunately ISO format
To give an example of what I mean, for a read or get KERNEL.BIN size you will need to specify
"/INIT/KERNEL.BIN;1"
As the filename. 
I'm only saying this so people won't have a surprise (which is bad news delayed ).

Okey, add this instead of NullFileDriver (or just add another one). If you do it, just test GAMEFILESYSTEM. In GameFileSystem you shoud add your driver instead of NullFileDriver.
This "/INIT/KERNEL.BIN;1" or "KERNEL.BIN" doesn't matter. Because we need GAMEFILESYSTEM for game internally handles files the way it used to be.
For usual files on hard disk we use REALFILESYSTEM.

ps: Use REALFILESYSTEM to load ISO and read from it. RealFileSystem shoud incapsulate all file reading functions.

695

Q-Gears / ChangeLog

« on: 2006-05-09 20:40:26 »

Revision 63
Case switch done, UpperCase/lowercase clean up. Clean compile on linux. (halkun)


Revision 59
Added all opcodes (dummy) to script parser/fixed scriptdump bugs.  (halkun)


Revision 49
WorldMapModule.h, WorldMapModule.cpp - add placeholder for worldmap module

displaytest.cpp - add M button to go to WorldMap Module.


Revision 47
Start documenting engine by doxygen.

config.h, config.cpp - switched to RString. Removed old param. Now it contains field dumper flag and name of field to load (temporary).

TypeDefine.h - moved u8 u16 u31 s8 s16 s32 definition to separate file from File class.

main.cpp, guitest.h, guitest.cpp, displaytest.h, displaytest.cpp, ModuleManager.h, ModuleManager.cpp, menu.h, partymenu.h - renamed Screen to Module.

displaytest.cpp - add N button to go to Field Module.

math.h, math.cpp - math for pathfinding in field (needs to be merged with other math later)

NoCopy.h, File.h, File.cpp, ModuleManager.h, ModuleManager.cpp, TimFile.h, TimFile.cpp, BinGZipFile.h, BinGZipFile.cpp, LzsFile.h, LzsFile.cpp - rewritten for doxygen and according to standart.

3dtypes.h - add matrix header.

display.h, display.cpp - add method to load camera matrix.

vector.h - add equal, not equal methods.

guibarexp.h, guibarexp.cpp - add fury, sadness states.

savemap.h, gamestate.cpp - fix savemap.

model.h, model.cpp - add placeholder for model.

fieldscreen.h, fieldscreen.cpp, datfile.h, datfile.cpp - add Field Modile (load walkmesh, set camera).

Revision 28

Move all class copy restrictions to NoCopy template.

Create "Dat" file loader for fields.

Create Field screen class.


Revision 30

New RString class implemented. Based on StdString template.

Logger switched to RString.

itoa removed from Utilites.


Revision 31

Add Tim handling class and example in displaytest.cpp

Some small fixes.


Revision 32

Small fixes with struct aligment in SaveBMP and with picture width in TimFile.


Revision 40

Added FFVII GUI support with 2 types of font, counter and pointer and gui testing screen.
Moved all testing screen to separate dir.
Add kernel.
Moved config and logger to utilites.
Added some finor fixes and functions to help with all changes.

Revision 43
Create Timer.
Create a lot of window elements.
Create 'Party Menu'
Add a lot of things to GuiTest.
Add loader for data in database.
Fix small errors.

696

Q-Gears / Re: Todo list

« on: 2006-05-09 20:32:38 »

As for the file driver class, I asked what we wanted in terms of an interface.  I will work on the Image File driver if I have an idea of what we want it to do.  I made the basic ISO class to allow reading sectors and some rudimentary information fetching.  The ISO9660 version of the game (IE PS1) boots differently than the PC as it appears those who converted it for the PC created a different kernel system beneath the script engine.   From that I believe we have a sort of answer to the question.  Perhaps we should look at the script system a bit more and determine where to go from there.  It seems all things point to the script as the guiding method to our madness.

Cyb

The only thing we need from framework - reading of specific files. All inner work are up to you.

unsigned int GetFileSize(const std::string &path)
bool ReadFile(const std::string &path, const void* buffer, const unsigned int start, const unsigned int length)

this two funcions shoud be enough (maybe later we need more, for video for example). But for the first fime this should be enough.

I don't know the way how real game engine handles file reading. Disk names or specifis ones (maybe from some file table). But this file uniq name should be given to function as path (maybe not as string).

697

Q-Gears / About defines and platform specific.

« on: 2006-05-09 20:22:31 »

1) We must use as little defines as posible because it will be hard to support code futher on.
2) We must use as little platform specific functions as posible.

int
#ifdef MACOSX
SDL_main
#else
main
#endif
(int argc, char *argv[])

Why mac use SDL_main instead of main?
All SDL code hidden in the WindowSDL class. If we deside to move to something else macos won't be working at all.
ps: macos CAN work with usual main function.


About itoa. I has no idea that GCC doesn't has this funcions. I'll replace this with something else.
I was thinking about use StdString - std::string convenience wrapper. It has a lot of usefull addition to standart string.


Tell me if something doesnt compile under mac or linux,it's better redone things or two, but has understandable and logical platform independent code.

698

Q-Gears / Todo list

« on: 2006-05-09 16:46:55 »

Halkun, let's define here what needs to be done.

1) we need catch your segmentation falls. (I checked it on my Linux - everything is working fine)
2) I need to move all singleton classes code to single template and derived all of them from there.
3) We need to create disk or image driver. I create NullFileDriver class, it needs to be replaced with appropriate image fole driver.
4) We need to initialize savemap and load there data from kernel. (I create BinGZipFile loader so it will be easy)

what is next?

699

Scripting and Reverse Engineering / Engine fantasy.

« on: 2006-04-16 20:18:15 »

Give me a bit to fill it out.

Here it is. http://server.titansoft.ru/akari/engine_ffvii.rar

It still does nothing. But it initialize SDL window and load gamestate with savemap. =)

ps: It has config and logger too. Give me some time to inplement basic OGL render and SDL input handler.

700

Scripting and Reverse Engineering / Engine fantasy.

« on: 2006-04-15 20:19:30 »

Finished first version of Savemap struct and GameState class that incapsulate Savemap.

http://server.titansoft.ru/akari/gamestate.zip

There are a lot of mistakes in Wiki and Gears in description of Savemap. Anyway I tested beginning of it and very end - it works correctly. The middle part are just array for time being. I dont think it makes matter now.

Next I create method to initialize Savemap from Kernel.
Is some file system already created? Or I will use standart C functions?