Eclipse (getting it)

[Cyberman]

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

[Cyberman]

The rest of this thread will be dedicated too Eclipse and it's relation to the Q-gears project.

I'm not certain people understand what Eclipse is so if you aren't familiar with it I recomend this URL as well as the Eclipse Wiki.

Aside from that things to understand about Eclipse

Automake and Autoconfig are in progress(proposal portion) to be supported I just haven't been able to find the status of that portion.  Consequences? This is a good thing for WIN32, Linux, and MAC support, I'm uncertain about anything else.

Subclipse is a SVN Client plugin for Eclipse this could make submitting changes and performing updates easier.  At the very least it will make managing things easier.  Currently this plugin is a WIP.  However it will become something a bit more important from the management perspective.  Consider that using it will be identical on windows or Linux from the same UI.

Eclipse is not just for C it's for mutliple language types, this is extremely important to keep in mind.  Why? Do we want to support say script editing and generating? Well within the Eclipse framework this could become quite easy to do.  It supports JDT (Java Developement Tools) and C/C++ were added afterword (CDT).  This also means making and supporting a script compilor is possible.  It may be possible to build and maintain tools for Eclipse for Q-gears FF7 Xeno gears kitchen sink engine (just like JRE is supported).

Debugging scripts in Q-gears, a plugin for Eclipse indeed could make this relatively easy.  I have just started looking into this possibility.

I've used Eclipse on both Windows and Linux.  So? They work the same.  The only difference is setting up the menus in Linux (windows it's done for you in Linux you have to edit your menus WOOPIE).  What about the MAC? I don't know yet, but I don't think it's an issue.  Considering the great differences between windows and Linux and using the UI is identical in function I think that says a lot.

Not much else to add at the moment.  I know people hate using something new, however Eclipse is becoming more common for a lot of comercial products that assist code management etc.

Hopefully I'll be able to find graphical tools for helping make Q-gears GUI display consistant and identical on MOST platforms.  As I've said I am working on support for the Palm protein platform (Xscale based units).  I will say this, don't expect this to run on a cheap $100 Z22 (LOL), because it's screen is 160x160 and FF7's display is 320x224 minimum.  I think an E2 will be the minimum.

Eclipse is a nice one stop multi platform IDE with big company support. Borland has ceased making IDE's (for a few reasons) and is now supporting it and Visual Studio.

This is for discusion it means we talk about pro's and con's and ask hard questions about viability etc.

Cyb - have fun ... with CODE!

[Tinnus]

(sorry for the off-topic)

Protein? You surely are not going to use the actual Protein API that's supposed to work on Palm OS Cobalt (ie: 6.0)?

That really won't take you anywhere

Use the current 5.x API since that will run on any current devices... There are no devices to date with the Cobalt (6.0) OS and probably there won't be thanks to the new ALP (Linux Platform) stuff coming from Access/PalmSource.

Supporting low-end and low-res devices like the Z22 will probably be very easy too.

I have Vincent ported and running. Still too slow for my tastes though. Palm OS has a tendency to run things slower than other systems... In any case, tell me if you want my code or just do it yourself, it shouldn't be hard.

Depending on the way the rendering in Q-Gears works, I might be able to give you a faster software renderer to work with It's not mine though so I'd need to get permission first.

In any case, I'll take a look at all of the Q-Gears source code. The whole idea is VERY tempting to me.

P.S.: you just crushed my plans of doing a Palm OS port of this hehe. But be sure to ask me if you have any problems developing for Palm OS (it will be a pain, trust me). Just to get started in all that 68k/ARM mess...

[Cyberman]

(sorry for the off-topic)

Protein? You surely are not going to use the actual Protein API that's supposed to work on Palm OS Cobalt (ie: 6.0)?

Was debating protien but it seems the suport for it is a bit enemic.

That really won't take you anywhere

Use the current 5.x API since that will run on any current devices... There are no devices to date with the Cobalt (6.0) OS and probably there won't be thanks to the new ALP (Linux Platform) stuff coming from Access/PalmSource.

Supporting low-end and low-res devices like the Z22 will probably be very easy too.

That explains the zero forward movement of Protein

I have Vincent ported and running. Still too slow for my tastes though. Palm OS has a tendency to run things slower than other systems... In any case, tell me if you want my code or just do it yourself, it shouldn't be hard.

Vincent (OpenGL ES) is the only portable way to support it unfortunately.

Depending on the way the rendering in Q-Gears works, I might be able to give you a faster software renderer to work with It's not mine though so I'd need to get permission first.

The engine is currently 100% OpenGL so special engines are a bit of a problem.

In any case, I'll take a look at all of the Q-Gears source code. The whole idea is VERY tempting to me.

LOL ehh I've been working on the ISO file system support for FF7 Xenogears is supported (ISO support should be easy for that).

Fortunately FF7 is not enormously demanding in terms of Rendering. The 3d is mixed with 2d layers.  It does require double buffering for rendering or a buffer to render the next frame in at least.

P.S.: you just crushed my plans of doing a Palm OS port of this hehe. But be sure to ask me if you have any problems developing for Palm OS (it will be a pain, trust me). Just to get started in all that 68k/ARM mess...

FF7 cannot operate on a 68k CPU ... not enough power.  ARM only operation will have to be supported.  The old dragon ball processors are too enemic in power.  It requires a 16bit R5G5B5 display.  It also requires 320x224 resolution.  One needs are fair amount of RAM as well.  It ran on the PS1 with 2M of RAM and 1M VRAM.  Without hardware assistance like on the PS1 it will take about 4M of RAM. The Z22 is a bit too small I suspect.   The display still requires rendering to a pair of buffers irregardless.  Running the video AND rendering 3d at the same time might be a bit of a problem as well.  It will need lots of tightly coupled code for 3d support and Motion JPEG decoding.

Cyb

[tinnus]

FF7 cannot operate on a 68k CPU ... not enough power.  ARM only operation will have to be supported.  The old dragon ball processors are too enemic in power.

Of course I know that. Whta I mean is that in Palm OS 5.x, even if you will run ARM code, your program must start as 68k code and then launch the ARM native code from that.

Trust me, you'll hate this stuff when you start to mess with it.

But first thing: if you simply write a normal OS5 app and compiles it, it will be 68k. OS5 emulates the 68k to maintain compatibility but ALL programs, even those that plan to use ARM code, must start as 68k. Read on PACE, PNOs, and stuff.

It requires a 16bit R5G5B5 display.  It also requires 320x224 resolution.  One needs are fair amount of RAM as well.  It ran on the PS1 with 2M of RAM and 1M VRAM.  Without hardware assistance like on the PS1 it will take about 4M of RAM.

I know what it requires... I've been working for some time now on psx4all and the Palm version (psx4palm) although a public release hasn't been made yet... I had fullspeed in field last time I played FF7 on my LifeDrive, hehe. Haven't touched it in a while though, so with the current additions battle should run a lot better.

The Z22 is a bit too small I suspect.   The display still requires rendering to a pair of buffers irregardless.  Running the video AND rendering 3d at the same time might be a bit of a problem as well.  It will need lots of tightly coupled code for 3d support and Motion JPEG decoding.

You don't seem to know much about the innards of the Palm models. Let me tell you something: all the new models--T5, TX, LifeDrive, Treo 600/650/700P, Z22, T|E2 use NVFS--non-volatile file system. That means that what Palm states as "internal memory" is flash, and they all have the same amount of real RAM, a 32M chip. From what I think 8M is for the system. Then there's something called the DBCache where the OS stores the databses ("files") when you tell a program to run--problem is, it doesn't delete them after the program has ended, only when it's full--hence the "cache".

Now, what's left of the RAM chip is the dynamic heap which is pre-defined to 4MB (IIRC). From that you usually only have around 2.5-3.5 and it's fragmented. Which means you probably won't go very far without UDMH on these.

Well, to sum up, what I want to say is: The only difference between, say, the TX and the Z22 (in power, not fancy features) is the CPU. The TX has cool stuff like BT and Wi-Fi but that doesn't help much for our case... The Z22 has a 160x160 screen. So what? Just render stuff half the size...

Now about the 3D. Palm OS is slow enough already, Vincent won't get you anywhere useful, especially in battles or the world map where there are a LOT of polygons. Vincent has just too much stuff that won't be used in FF7 but still cause an overhead. Unless you find out I did something wrong when porting... since I talked with the author and he told me Pocket PC got around 3x more speed. But I don't doubt it's PalmOS' fault--psx4all runs 3x faster on equivalent devices too like the Zaurus compared to the LifeDrive.

Oh yeah... NVFS devices run EVEN MORE slower because NVFS itself is a thread that keeps running in background and doing its (stupid) stuff.

Well, I just have an advice for you. Go with calm... if you've never done any Palm OS before, you'll have a REALLY hard time.

[Cyberman]

Of course I know that. Whta I mean is that in Palm OS 5.x, even if you will run ARM code, your program must start as 68k code and then launch the ARM native code from that.

Trust me, you'll hate this stuff when you start to mess with it.

Ahhh sideways mobility! That's truely a sad way to handle things.

But first thing: if you simply write a normal OS5 app and compiles it, it will be 68k. OS5 emulates the 68k to maintain compatibility but ALL programs, even those that plan to use ARM code, must start as 68k. Read on PACE, PNOs, and stuff.

Ehh sounds rather droll.. here I was hoping they had protein, I had asked several times on the PalmDev list with very careful questions.  I guess they decided to do things differently.

I know what it requires... I've been working for some time now on psx4all and the Palm version (psx4palm) although a public release hasn't been made yet... I had fullspeed in field last time I played FF7 on my LifeDrive, hehe. Haven't touched it in a while though, so with the current additions battle should run a lot better.

Hmmmm interesting.  I suppose you used a native ARM code for performing GPU operations?

You don't seem to know much about the innards of the Palm models. Let me tell you something: all the new models--T5, TX, LifeDrive, Treo 600/650/700P, Z22, T|E2 use NVFS--non-volatile file system. That means that what Palm states as "internal memory" is flash, and they all have the same amount of real RAM, a 32M chip. From what I think 8M is for the system. Then there's something called the DBCache where the OS stores the databses ("files") when you tell a program to run--problem is, it doesn't delete them after the program has ended, only when it's full--hence the "cache".

Now, what's left of the RAM chip is the dynamic heap which is pre-defined to 4MB (IIRC). From that you usually only have around 2.5-3.5 and it's fragmented. Which means you probably won't go very far without UDMH on these.

In other words you get what you get.  Fortunately we are not making a PS1 emulator but an FF7 engine.  This makes a few things easier.  The application will need a fair chunk of memory for itself.  Then comes data loading and decompression.  Loading only requires an 8K buffer. Whereas the destination data is as large as 512K.  Much of the memory is swapped about in FF7's operation.

Well, to sum up, what I want to say is: The only difference between, say, the TX and the Z22 (in power, not fancy features) is the CPU. The TX has cool stuff like BT and Wi-Fi but that doesn't help much for our case... The Z22 has a 160x160 screen. So what? Just render stuff half the size...

Mmmm probably render to a buffer and then scale to the display.  Might need some blending to keep it from looking too bad.  However to be honest it would be better to put a restriction of 320x224 for display area

Now about the 3D. Palm OS is slow enough already, Vincent won't get you anywh[ere useful, especially in battles or the world map where there are a LOT of polygons. Vincent has just too much stuff that won't be used in FF7 but still cause an overhead. Unless you find out I did something wrong when porting... since I talked with the author and he told me Pocket PC got around 3x more speed. But I don't doubt it's PalmOS' fault--psx4all runs 3x faster on equivalent devices too like the Zaurus compared to the LifeDrive.[/qoute]I'm not sure what features are being used in OGL.  The simple thinking approach is to assume Vincent would need to be statically linked and therefore only the parts of Vincent that are used (IE dependancies from the executable) are linked and or used.  Since this thing uses the Xscale processor the LCD is likely to be the major limitation in the graphics.  This means the Z22 et al since it has the same amount of memory, won't care what Q-gears does.  So rendering to a buffer I guess on the Palm will be it, and dumping it to the display (lame and slow) will be the method of operation.  FF7's actual framerate is 15FPS in battle.  I'm not sure of the field I suspect 30FPS there.

The worst case would be a custom rendering system for Q-gears and considering the modularity of it this might not be too bad.  I prefer not to have to reinvent the wheel. 

Oh yeah... NVFS devices run EVEN MORE slower because NVFS itself is a thread that keeps running in background and doing its (stupid) stuff.

Well, I just have an advice for you. Go with calm... if you've never done any Palm OS before, you'll have a REALLY hard time.

Ack... You are joking right? That's not even funny.  Well I suppose it might be the way things are.  The idea was internal App for Q-gears and register file type .ISO for Q-gears and set up a few paths.  Save data would be kept in the Application 'database'.  Hmmm it would have been wiser to move to protein early on instead of what they did do.  It's politics though so I guess it matters not.  Most of my developement has been with NO OS. I've had to MYO everything from scratch a lot.

Describe 'calm' it doesn't hit any mental reference in my brain

Esrtwhile my basement has been being traumatized so I have little access to either of my developement systems.
So I will do perfunctory things in the mean time like formulate a new port plan of some sort.

[Tinnus]

Hmmmm interesting.  I suppose you used a native ARM code for performing GPU operations?

I used native ARM code for performing EVERYTHING. That is, the entire emulator is compiled into an ARM onject and called from 68k.

In other words you get what you get.  Fortunately we are not making a PS1 emulator but an FF7 engine.  This makes a few things easier.  The application will need a fair chunk of memory for itself.  Then comes data loading and decompression.  Loading only requires an 8K buffer. Whereas the destination data is as large as 512K.  Much of the memory is swapped about in FF7's operation.

It should work OK. I suppose it will use more memory than the original engine in the PS1 though.

Mmmm probably render to a buffer and then scale to the display.  Might need some blending to keep it from looking too bad.  However to be honest it would be better to put a restriction of 320x224 for display area

People would come after you then, haha.

Oh yeah, I think the menus are rendered as 512x240 in the PS1.

I'm not sure what features are being used in OGL.  The simple thinking approach is to assume Vincent would need to be statically linked and therefore only the parts of Vincent that are used (IE dependancies from the executable) are linked and or used.  Since this thing uses the Xscale processor the LCD is likely to be the major limitation in the graphics.  This means the Z22 et al since it has the same amount of memory, won't care what Q-gears does.  So rendering to a buffer I guess on the Palm will be it, and dumping it to the display (lame and slow) will be the method of operation.  FF7's actual framerate is 15FPS in battle.  I'm not sure of the field I suspect 30FPS there.

I suspect 20. Can't remember though.

Oh yeah you can't access the LCD in PalmOS. Only the window bitmap.

Really, you can't access ANYTHING in the HW with Palm OS pretty much.

The worst case would be a custom rendering system for Q-gears and considering the modularity of it this might not be too bad.  I prefer not to have to reinvent the wheel. 

I don't think using OpenGL directly is good is big portability is aimed. Especially since the stuff Q-Gears uses/will use is fairly simple.

Ack... You are joking right? That's not even funny.  Well I suppose it might be the way things are.  The idea was internal App for Q-gears and register file type .ISO for Q-gears and set up a few paths.  Save data would be kept in the Application 'database'.  Hmmm it would have been wiser to move to protein early on instead of what they did do.  It's politics though so I guess it matters not.

Unfortunately I'm not joking. Be prepared...

Describe 'calm' it doesn't hit any mental reference in my brain

Hmm. Try not to hit your head too hard on the monitor.

Meanwhile feel free to ask me about anything (and ask me to port it in case you give up).

[Synergy Blades]

I'm not sure of the field I suspect 30FPS there.

I suspect 20. Can't remember though.

Cyb's right, it's 30.

[Cyberman]

I used native ARM code for performing EVERYTHING. That is, the entire emulator is compiled into an ARM onject and called from 68k.

I was concerned that most of the AP would be 68K... I guess not...

It should work OK. I suppose it will use more memory than the original engine in the PS1 though.

That is almost a given because of hardware aceleration on the PS1

People would come after you then, haha.

Oh yeah, I think the menus are rendered as 512x240 in the PS1.

Hmmm I'm not sure myself.  640x480 it might have been, LOL.  I'll have to check using Peops set to exact window size (sheesh).

Oh yeah you can't access the LCD in PalmOS. Only the window bitmap.

Really, you can't access ANYTHING in the HW with Palm OS pretty much.

I don't think using OpenGL directly is good is big portability is aimed. Especially since the stuff Q-Gears uses/will use is fairly simple.

Well for the moment yes.  However add Xenogears FF8, FF9, ChronoCross and VagrantStory, things may get a bit more interesting.  The goal is to hit FF7 first.  Then the others are likely next on the list of targets.

Unfortunately I'm not joking. Be prepared...

Nothing I or you can do about it. What they do is what they do.

Meanwhile feel free to ask me about anything (and ask me to port it in case you give up).

Well I can help with the port if you wish to do it.  I've done a bit of work on the polygon texturing (necessary for rendering the internal 4bit TIM textures to something useful in a program).  Stripping Vincent down to the simplest (OGL 1.3 complience equivalent) level of support.
Enhancement features will have to be ignored for the Palm version I suppose

Cyb