Hikari (v0.3)
- manowar
- Orc
- Posts: 419
- Joined: Thu Apr 07, 2005 2:11 pm
- Location: UK
- Contact:
- ajs15822
- OGRE Expert User
- Posts: 570
- Joined: Mon Jan 02, 2006 2:05 am
- Location: Texas
- x 2
- Contact:
To be absolutely sure, you can open up regedit, navigate to COMPUTER\HKEY_CLASSES_ROOT and scroll down to "ShockwaveFlash.ShockwaveFlash". You should also see "ShockwaveFlash.ShockwaveFlash.9" as an entry a little below that and "ShockWaveFlash.ShockwaveFlash\CurVer" should have a value of "ShockwaveFlash.ShockwaveFlash.9".manowar wrote:Hum, that's weird...flash 9 is definitely installed on my machine. I even have just reinstalled the player from the link you gave me.
Flash 6 must be referenced somewhere on my computer. Anyway thanks for the quick reply.
- manowar
- Orc
- Posts: 419
- Joined: Thu Apr 07, 2005 2:11 pm
- Location: UK
- Contact:
Thanks. I used the adobe flash uninstaller:
http://kb.adobe.com/selfservice/viewCon ... d=tn_14157
Then reinstalled flash 9 player. It still did not work.
I finally installed http://www.adobe.com/support/flashplaye ... ctiveX.zip
And every is fine now. I finally managed to compile it. Not too sure what messed up everything on my machine. Thanks a lot for your help.
http://kb.adobe.com/selfservice/viewCon ... d=tn_14157
Then reinstalled flash 9 player. It still did not work.
I finally installed http://www.adobe.com/support/flashplaye ... ctiveX.zip
And every is fine now. I finally managed to compile it. Not too sure what messed up everything on my machine. Thanks a lot for your help.
- DanielSefton
- Ogre Magi
- Posts: 1235
- Joined: Fri Oct 26, 2007 12:36 am
- Location: Mountain View, CA
- x 10
- Contact:
I need to access a member function for bind(), but I can't get it to work in main().
myControl->bind("exitPress", Hikari::FlashDelegate(this, &MainMenuState::HikariMenu::onExitPress));
myControl->bind("exitPress", Hikari::FlashDelegate(this, &MainMenuState::HikariMenu::onExitPress));
What do I need in place of "this" to get it to work in main()?1>..\..\src\main.cpp(261) : error C2673: 'main' : global functions do not have 'this' pointers
1>..\..\src\main.cpp(261) : error C2661: 'Hikari::Impl::fastdelegate::FastDelegate2<Param1,Param2,RetType>::FastDelegate2' : no overloaded function takes 2 arguments
1> with
1> [
1> Param1=Hikari::FlashControl *,
1> Param2=const Hikari::Arguments &,
1> RetType=Hikari::FlashValue
1> ]
- Zigmar
- Halfling
- Posts: 40
- Joined: Tue Dec 18, 2007 2:09 pm
- Location: Israel
Good job! We have been using a custom solution to have a flash ui and embeddable flash textures (i.e. youtube videos on screen of tv in 3D space), but your implementation seems to be more robust and clean
Maybe we even would able to adapt the Hikari in future and contribute some of our knolange to the project. However, we are striving for a multiplatform solution, which probably means to do something with simulated container for firefox/safari plugin, wich could be also cool addition to Hikari itself if such solution is possible.
Maybe we even would able to adapt the Hikari in future and contribute some of our knolange to the project. However, we are striving for a multiplatform solution, which probably means to do something with simulated container for firefox/safari plugin, wich could be also cool addition to Hikari itself if such solution is possible.
- Noman
- OGRE Retired Team Member
- Posts: 714
- Joined: Mon Jan 31, 2005 7:21 pm
- Location: Israel
- x 2
- Contact:
It sounds like you are making the call from a global scope. Instead of 'this' you should have a pointer to the MainMenuState::HikariMenu instance that will receive the calls. (If you were inside a HikariMenu method, 'this' would be exactly that)DanielSefton wrote:I need to access a member function for bind(), but I can't get it to work in main().
myControl->bind("exitPress", Hikari::FlashDelegate(this, &MainMenuState::HikariMenu::onExitPress));
What do I need in place of "this" to get it to work in main()?1>..\..\src\main.cpp(261) : error C2673: 'main' : global functions do not have 'this' pointers
1>..\..\src\main.cpp(261) : error C2661: 'Hikari::Impl::fastdelegate::FastDelegate2<Param1,Param2,RetType>::FastDelegate2' : no overloaded function takes 2 arguments
1> with
1> [
1> Param1=Hikari::FlashControl *,
1> Param2=const Hikari::Arguments &,
1> RetType=Hikari::FlashValue
1> ]
- DanielSefton
- Ogre Magi
- Posts: 1235
- Joined: Fri Oct 26, 2007 12:36 am
- Location: Mountain View, CA
- x 10
- Contact:
You mean like this?It sounds like you are making the call from a global scope. Instead of 'this' you should have a pointer to the MainMenuState::HikariMenu instance that will receive the calls. (If you were inside a HikariMenu method, 'this' would be exactly that)
Code: Select all
MainMenuState::HikariMenu* pHikariMenu = new MainMenuState::HikariMenu(hikariMgr, myControl);
myControl->bind("exitClick", Hikari::FlashDelegate(pHikariMenu, &MainMenuState::HikariMenu::onExitClick));
So I need to populate it with the full 3 arguments? What's the third, because ajs didn't use it in his example...1>..\..\src\main.cpp(468) : error C2661: 'Hikari::Impl::fastdelegate::FastDelegate2<Param1,Param2,RetType>::FastDelegate2' : no overloaded function takes 2 arguments
1> with
1> [
1> Param1=Hikari::FlashControl *,
1> Param2=const Hikari::Arguments &,
1> RetType=Hikari::FlashValue
1> ]
- ajs15822
- OGRE Expert User
- Posts: 570
- Joined: Mon Jan 02, 2006 2:05 am
- Location: Texas
- x 2
- Contact:
Awesome! I would love some help.Zigmar wrote:Good job! We have been using a custom solution to have a flash ui and embeddable flash textures (i.e. youtube videos on screen of tv in 3D space), but your implementation seems to be more robust and clean
Maybe we even would able to adapt the Hikari in future and contribute some of our knolange to the project. However, we are striving for a multiplatform solution, which probably means to do something with simulated container for firefox/safari plugin, wich could be also cool addition to Hikari itself if such solution is possible.
I suspect that your callback function (MainMenuState::HikariMenu::onExitClick) does not have the correct function signature. It should follow this form (note the return type and arguments):DanielSefton wrote:You mean like this?It sounds like you are making the call from a global scope. Instead of 'this' you should have a pointer to the MainMenuState::HikariMenu instance that will receive the calls. (If you were inside a HikariMenu method, 'this' would be exactly that)
Well, 'this' error has disappeared, but I'm still getting this error (silly puns):Code: Select all
MainMenuState::HikariMenu* pHikariMenu = new MainMenuState::HikariMenu(hikariMgr, myControl); myControl->bind("exitClick", Hikari::FlashDelegate(pHikariMenu, &MainMenuState::HikariMenu::onExitClick));
So I need to populate it with the full 3 arguments? What's the third, because ajs didn't use it in his example...1>..\..\src\main.cpp(468) : error C2661: 'Hikari::Impl::fastdelegate::FastDelegate2<Param1,Param2,RetType>::FastDelegate2' : no overloaded function takes 2 arguments
1> with
1> [
1> Param1=Hikari::FlashControl *,
1> Param2=const Hikari::Arguments &,
1> RetType=Hikari::FlashValue
1> ]
Code: Select all
FlashValue MyClass::myFunction(FlashControl* caller, const Arguments& args)
{
// handle stuff
return FLASH_VOID;
}
- DanielSefton
- Ogre Magi
- Posts: 1235
- Joined: Fri Oct 26, 2007 12:36 am
- Location: Mountain View, CA
- x 10
- Contact:
Well... It looks like this:ajs15822 wrote:I suspect that your callback function (MainMenuState::HikariMenu::onExitClick) does not have the correct function signature. It should follow this form (note the return type and arguments):
Code: Select all
FlashValue MyClass::myFunction(FlashControl* caller, const Arguments& args) { // handle stuff return FLASH_VOID; }
Code: Select all
Hikari::FlashValue MainMenuState::HikariMenu::onExitClick(Hikari::FlashControl* pFlashControl, const Hikari::Args& args)
{
//stuff
return FLASH_VOID;
}
Not sure if it will help, but I'll post the whole code anyway (with Hikari::Arguments):1>include\MainMenuState.h(18) : error C2371: 'Hikari::Arguments' : redefinition; different basic types
1> include\hikari\FlashValue.h(140) : see declaration of 'Hikari::Arguments'
1>..\..\src\main.cpp(468) : error C2661: 'Hikari::Impl::fastdelegate::FastDelegate2<Param1,Param2,RetType>::FastDelegate2' : no overloaded function takes 2 arguments
1> with
1> [
1> Param1=Hikari::FlashControl *,
1> Param2=const Hikari::Arguments &,
1> RetType=Hikari::FlashValue
1> ]
1>MainMenuState.cpp
1>include\hikari\FlashValue.h(140) : error C2371: 'Hikari::Arguments' : redefinition; different basic types
1> include\MainMenuState.h(18) : see declaration of 'Hikari::Arguments'
1>include\hikari\FlashValue.h(153) : error C2504: 'Hikari::Arguments' : base class undefined
1>include\hikari\FlashControl.h(226) : error C2440: 'default argument' : cannot convert from 'Hikari::Args' to 'const Hikari::Arguments &'
1> Reason: cannot convert from 'Hikari::Args' to 'const Hikari::Arguments'
1> Source or target has incomplete type
MainMenuState.h:
Code: Select all
namespace Hikari
{
class HikariManager;
class FlashControl;
class FlashValue;
class Arguments;
}
class MainMenuState
{
public:
class HikariMenu
{
public:
HikariMenu(Hikari::HikariManager* pHikariManager, Hikari::FlashControl* pFlashControl);
~HikariMenu();
Hikari::FlashValue onExitClick(Hikari::FlashControl* caller, const Hikari::Arguments& args);
private:
Hikari::HikariManager* m_pHikariManager;
Hikari::FlashControl* m_pFlashControl;
};
};
Code: Select all
#include "MainMenuState.h"
#include "Hikari.h"
MainMenuState::HikariMenu::HikariMenu(Hikari::HikariManager* pHikariManager, Hikari::FlashControl* pFlashControl)
{
m_pHikariManager = pHikariManager;
m_pFlashControl = pFlashControl;
}
MainMenuState::HikariMenu::~HikariMenu()
{
}
Hikari::FlashValue MainMenuState::HikariMenu::onExitClick(Hikari::FlashControl* pFlashControl, const Hikari::Arguments& args)
{
//stuff
return FLASH_VOID;
}
Code: Select all
MainMenuState::HikariMenu* pHikariMenu = new MainMenuState::HikariMenu(hikariMgr, myControl);
myControl->bind("exitClick", Hikari::FlashDelegate(pHikariMenu, &MainMenuState::HikariMenu::onExitClick));
- ajs15822
- OGRE Expert User
- Posts: 570
- Joined: Mon Jan 02, 2006 2:05 am
- Location: Texas
- x 2
- Contact:
The second parameter of the callback must be "const Hikari::Arguments&", there is no escaping that. (Just because the Hikari::Args helper class implicitly converts to Hikari::Arguments, they are not the same thing)
The problem you are having comes down to your forward declaration:
Hikari::Arguments is not a class, it is a typedef for "std::vector<FlashValue>".
Hence the error:
The problem you are having comes down to your forward declaration:
Code: Select all
namespace Hikari
{
class HikariManager;
class FlashControl;
class FlashValue;
class Arguments;
}
Hence the error:
Code: Select all
include\hikari\FlashValue.h(140) : error C2371: 'Hikari::Arguments' : redefinition; different basic types
- DanielSefton
- Ogre Magi
- Posts: 1235
- Joined: Fri Oct 26, 2007 12:36 am
- Location: Mountain View, CA
- x 10
- Contact:
Mhm. Though, if I comment that out, why does it complain that it's not a member of Hikari?ajs15822 wrote:Hikari::Arguments is not a class, it is a typedef for "std::vector<FlashValue>".
Code: Select all
1>include\MainMenuState.h(53) : error C2039: 'Arguments' : is not a member of 'Hikari'
1>include\MainMenuState.h(53) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>include\MainMenuState.h(53) : error C2143: syntax error : missing ',' before '&'
1>..\..\src\MainMenuState.cpp(81) : error C2511: 'Hikari::FlashValue MainMenuState::HikariMenu::onExitClick(Hikari::FlashControl *,const Hikari::Arguments &)' : overloaded member function not found in 'MainMenuState::HikariMenu'
1> include\MainMenuState.h(48) : see declaration of 'MainMenuState::HikariMenu'
Btw, do you know how Scaleform works? That uses Flash, but I'm wondering whether or not you are planning to take Hikari in that direction. It's also cross-platform, so somehow they've managed to get Flash/C++ to work on Mac/Linux. My question is, what will we see in future versions of Hikari?
- ajs15822
- OGRE Expert User
- Posts: 570
- Joined: Mon Jan 02, 2006 2:05 am
- Location: Texas
- x 2
- Contact:
I think you would make it a lot easier on yourself if you just forgot about the forward-declarations and included "Hikari.h" directly in your header.
Hikari is less ambitious-- it uses the actual Adobe Flash software renderer and blits the result to a dynamic texture.
Comparing the two:
- Hikari is totally compatible with the actual Flash spec and uses the native ActionScript engine, Scaleform has limited compatibility
- Hikari uses a software renderer (at least until Flash 10+) and blits to a texture (slower rendering during high animation), Scaleform uses a hardware renderer and its performance is independent of movie size
- Hikari is ideal for movies that have a limited amount of animation because between texture updates the FlashControl acts as a billboard, whereas Scaleform is less ideal for such situations because the geometric complexity (the triangle count) of the movie is a constant factor.
- Hikari benefits directly from Adobe's Flash Player updates, Scaleform does not
- Hikari is Windows-only (for now), Scaleform is cross-platform
- Hikari is totally free and open-source, Scaleform is absolutely not (quoted at $10,000+)
Scaleform, based on GameSWF, is totally different from Hikari-- using a totally custom implementation, it loads SWF files, interprets the ActionScript, tesselates the vectors into triangles, and ultimately uses 3D hardware API's (OpenGL/DX) to render/composite the geometry into the final product.Btw, do you know how Scaleform works? That uses Flash, but I'm wondering whether or not you are planning to take Hikari in that direction. It's also cross-platform, so somehow they've managed to get Flash/C++ to work on Mac/Linux. My question is, what will we see in future versions of Hikari?
Hikari is less ambitious-- it uses the actual Adobe Flash software renderer and blits the result to a dynamic texture.
Comparing the two:
- Hikari is totally compatible with the actual Flash spec and uses the native ActionScript engine, Scaleform has limited compatibility
- Hikari uses a software renderer (at least until Flash 10+) and blits to a texture (slower rendering during high animation), Scaleform uses a hardware renderer and its performance is independent of movie size
- Hikari is ideal for movies that have a limited amount of animation because between texture updates the FlashControl acts as a billboard, whereas Scaleform is less ideal for such situations because the geometric complexity (the triangle count) of the movie is a constant factor.
- Hikari benefits directly from Adobe's Flash Player updates, Scaleform does not
- Hikari is Windows-only (for now), Scaleform is cross-platform
- Hikari is totally free and open-source, Scaleform is absolutely not (quoted at $10,000+)
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
I'm not quite sure how much "Hardware rendering" will be in flash 10. I think it will be less than most people hope (if they knew what true hardware rendering would mean for Flash, I think most people would not be so keen on the idea). I'll need check with a few people who have the Flash 10 beta, but I believe most of the rendering is still done by the CPU.
- ajs15822
- OGRE Expert User
- Posts: 570
- Joined: Mon Jan 02, 2006 2:05 am
- Location: Texas
- x 2
- Contact:
Yeah, according to an actual Flash engineer, it seems that Flash 10's hardware-acceleration only applies to compositing and video-scaling. Nevertheless, I'm still excited to see that the player is moving towards GPU-acceleration.Praetor wrote:I'm not quite sure how much "Hardware rendering" will be in flash 10. I think it will be less than most people hope (if they knew what true hardware rendering would mean for Flash, I think most people would not be so keen on the idea). I'll need check with a few people who have the Flash 10 beta, but I believe most of the rendering is still done by the CPU.
- DanielSefton
- Ogre Magi
- Posts: 1235
- Joined: Fri Oct 26, 2007 12:36 am
- Location: Mountain View, CA
- x 10
- Contact:
Bah, I'm such an idiot sometimes. Thanks. Despite a successful compile, events still don't work. But I'll have a look tomorrow.ajs15822 wrote:I think you would make it a lot easier on yourself if you just forgot about the forward-declarations and included "Hikari.h" directly in your header.
I also noticed something strange with the buttons... If you add a 'down' state (third keyframe in any button symbol), it doesn't seem to work so well. Sometimes when I click the button, it doesn't reach its down state and looks as if you never pressed it. It's probably just me, but it might be worth taking a look. It's not a huge problem, just slightly irritating.
Would Hikari work well as a replacement for overlays? i.e. for HUD elements. Say, in my game I need a speedo and various other animated elements. Would it be efficient to overlay a SWF over the whole viewport, with a transparent canvas? How would I go about that?
Apart from cross-platform, Flash Player 10, speed improvements etc. Are there any other features you are planning to implement?
Sorry for my endless queries; anyone that owns Flash will know just how valuable something like this is. I've been looking for a Flash/C++ library for months (Navi was an overkill for what we needed). For a first release, Hikari is quite remarkable.
Last edited by DanielSefton on Wed Jun 11, 2008 8:48 am, edited 1 time in total.
-
- Greenskin
- Posts: 102
- Joined: Tue May 10, 2005 11:42 pm
- Location: SF, California
- Contact:
- DanielSefton
- Ogre Magi
- Posts: 1235
- Joined: Fri Oct 26, 2007 12:36 am
- Location: Mountain View, CA
- x 10
- Contact:
Ah, right. Of course. I was just paranoid that multiple SWFs would slow it down. Still wondering about the transparent canvas though (haven't had chance to look yet, it's probably something simple).Murphy wrote:No. Build the individual pieces and place them in the viewport at specific locations. This will support many resolutions and be much faster to render and copy.DanielSefton wrote:Would it be efficient to overlay a SWF over the whole viewport, with a transparent canvas?
-
- Kobold
- Posts: 29
- Joined: Wed Jun 27, 2007 5:24 pm
- DanielSefton
- Ogre Magi
- Posts: 1235
- Joined: Fri Oct 26, 2007 12:36 am
- Location: Mountain View, CA
- x 10
- Contact:
When creating a SWF instance, you can define the height and width as the dimensions of the viewport, then update it each frame to check for window resizing. Or just update the dimensions every time the user changes the resolution. For a full screen SWF, you will have to define a tiling background within Flash itself using ActionScript, then update the positions of the elements according to the size of the stage. There's various tutorials around the web; just search "full screen flash" in Google.dominic1988 wrote:just a curious question, does hikari supports multiple resolutions and is there a way to call variables inside actionscript from c++
Check out the Wiki page for info on communication between ActionScript and C++:
http://code.google.com/p/hikari-library ... munication
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
I'm not so much. Here's the issue: Flash's major selling point is that it works the same on all machines everywhere. Some may run faster, some slower, but it is all the same. As soon as you start putting in hardware-only paths that won't happen anymore. The most important thing about flash will be broken. I especially hope they resist the urge to add hardware-only features (like shaders).ajs15822 wrote: Yeah, according to an actual Flash engineer, it seems that Flash 10's hardware-acceleration only applies to compositing and video-scaling. Nevertheless, I'm still excited to see that the player is moving towards GPU-acceleration.
- DanielSefton
- Ogre Magi
- Posts: 1235
- Joined: Fri Oct 26, 2007 12:36 am
- Location: Mountain View, CA
- x 10
- Contact:
Actually, shaders are exactly what they are adding in FP10 with Astro. Which is one of the main reasons for Adobe using hardware acceleration. Yes Flash's major selling point is its independancy, but its biggest advantage is also its biggest disadvantage. Software rendering draws a line as to what Adobe can achieve e.g. true 3D was out of the question prior to version 10. Hardware acceleration is necessary to take it further.Praetor wrote:I'm not so much. Here's the issue: Flash's major selling point is that it works the same on all machines everywhere. Some may run faster, some slower, but it is all the same. As soon as you start putting in hardware-only paths that won't happen anymore. The most important thing about flash will be broken. I especially hope they resist the urge to add hardware-only features (like shaders).
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
Are you sure these are actual hardware shaders? If what I'm seeing about it is true then hardware is used for video, scaling, and compositing. The shader features could be available in the compositing portion, but I believe that has more to do with wmode than anything. The shaders may be a system designed to mimic hardware shaders but are in fact emulated completely in the CPU.
[EDIT] From what research I can pull up Hydra is "based" on GLSL (not necessarily meaning it translate into or is run through in any way. I believe they mean at the language level) and that the processing has "some elements of hardware acceleration." But then most of the comments about it reiterate that almost all of the rendering is still done on the CPU.
[EDIT] From what research I can pull up Hydra is "based" on GLSL (not necessarily meaning it translate into or is run through in any way. I believe they mean at the language level) and that the processing has "some elements of hardware acceleration." But then most of the comments about it reiterate that almost all of the rendering is still done on the CPU.
- DanielSefton
- Ogre Magi
- Posts: 1235
- Joined: Fri Oct 26, 2007 12:36 am
- Location: Mountain View, CA
- x 10
- Contact:
After banging my head against a brick wall for hours, I just noticed that you have to use AS3 for ExternalInterface() to work. Everything is perfect now!
So basically, you need Flash 8 and above. Otherwise your stuffed.
Did you mention that it required AS3? I don't recall, but if you did, then that's another case of my stupidity. You really need to make it obvious, otherwise anyone hoping to use AS2 will be scratching their head for eternity (like muggins here).
So basically, you need Flash 8 and above. Otherwise your stuffed.
Did you mention that it required AS3? I don't recall, but if you did, then that's another case of my stupidity. You really need to make it obvious, otherwise anyone hoping to use AS2 will be scratching their head for eternity (like muggins here).
- ajs15822
- OGRE Expert User
- Posts: 570
- Joined: Mon Jan 02, 2006 2:05 am
- Location: Texas
- x 2
- Contact:
You could theoretically create a Flash overlay that covers the entire viewport but unless you're really going to use a lot of the space, it's a waste of texture memory. As Murphy said, it's a bit more optimal to break your interface components down into multiple FlashControls (makes for faster update performance as well).DanielSefton wrote:Ah, right. Of course. I was just paranoid that multiple SWFs would slow it down. Still wondering about the transparent canvas though (haven't had chance to look yet, it's probably something simple).Murphy wrote:No. Build the individual pieces and place them in the viewport at specific locations. This will support many resolutions and be much faster to render and copy.DanielSefton wrote:Would it be efficient to overlay a SWF over the whole viewport, with a transparent canvas?
The SWF should scale to whatever dimensions you create the FlashControl with. To specify dimensions relative to the viewport, you could do something like this:dominic1988 wrote:just a curious question, does hikari supports multiple resolutions and is there a way to call variables inside actionscript from c++
Code: Select all
hikariMgr->createFlashOverlay("myControl", viewport, viewportWidth * 0.35, viewportHeight * 0.25, Position(TopLeft), 0);
I just looked it up and it seems that AS2 certainly does support ExternalInterface but its usage is a little different from AS3. Two things you need to be aware of:DanielSefton wrote:After banging my head against a brick wall for hours, I just noticed that you have to use AS3 for ExternalInterface() to work. Everything is perfect now!
So basically, you need Flash 8 and above. Otherwise your stuffed.
Did you mention that it required AS3? I don't recall, but if you did, then that's another case of my stupidity. You really need to make it obvious, otherwise anyone hoping to use AS2 will be scratching their head for eternity (like muggins here).
You need to explicitly import the ExternalInterface class:
Code: Select all
import flash.external.ExternalInterface;
Code: Select all
ExternalInterface.addCallback("myFunction", this, myFunction);
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact: