Windowed ORX

edited September 2011 in General discussions
Hi all,

I was wondering if it could be possible to use orx inside a child window in Win32.
I mean I'd like to use it in a control to make previews of animations, view created maps and so on.

I've got an idea but it's a quick and dirty way...my idea is to start a clean orx application and once the "game windows" is displayed I could find the window, build a parent frame and then make the "game windows" as a child of my parent frame.
I'd like to get rid of the console window and use mine instead.

I guess/hope there's a better way to implement that.
Do you have any suggestion?
«1

Comments

  • edited September 2011
    Hi!

    That'd be nice. I'm no expert in those kind of UI manipulation and I don't know if there's a portable way to do it. If you ever need to communicate with the display plugin in any way, you can use the config system as a non-intrusive communication channel.

    As for the console window, you can easily get rid of it by compiling for subsystem = windows, or something like this (don't remember the exact name). There are ways to redirect the standard and error outputs so that you get access to whatever text orx spits. :)
  • edited September 2011
    I know how to do that on Windows but it' not portable.

    I'll check the compilation flag and the way the system redirects it's output so I can see logs into a text control of a pseudo map/animation/level/physic/whateverelse editor.

    Many thanks
  • edited September 2011
    Well windows is a good start! :)

    Let me know if you encounter any issue, I'm really looking forward seeing what you get! :D

    I went the opposite direction for my needs: I built a minimalistic level editor made with orx, and I plan on adding more things like animationg editing, for example.
  • edited September 2011
    Today I try to implement the control. If I reach my goal, I'll give you the source code so you can put it somewhere (if needed by someone else).

    I think that for me it's better to make an editor usin standard controls because the main goal of the editor is to reduce the time spent making configuration files and I don't want to spend a lot of time making configuration files for the editor.
    Using standard controls i have standard controls ready to use so it's more quick to create the application and gives me more time to concentrate on features I need (and bug corrections).

    I don't promise anything about the editor, I don't have much spare time to spend on projects that are not my daily job...but if I create it I'll share the code so the community can help me to make it to grow and port it to other platforms.

    The main problem with the "port" is that I don't know well Qt or Gtk so I don't know how to make the orx window as a child of my frame...I think I will do in the MFC way, may be I can try with .NET too so "mono" people can try to port it.

    But for now all this is just a discussion about fried air and nothing else :)

    Bye
  • edited September 2011
    .NET is a good idea as it'll please most of the windows and *nix users, I think. Of course, no pressure, but whatever you come up with will be greatly appreciated as having an helpful editor is by far the #1 wanted feature. :)

    As a side note, you don't have to write any config if you don't feel like it, orx can be piloted entirely programmatically but you lose a lot of advantages by doing so. A mix is most of the time the best way to go: writing by hand all unique piece of config data and generating programmatically what can be automated (that works great especially for tedious tasks such as sprite sheets and animation).

    Anyway good luck and don't hesitate if you have any questions. :)
  • edited September 2011
    I saw that's possible to programmatically pilot all features, but it's not what I want to do.
    The power of the orx library it to use it as data driven library but to get all advantages it needs a way to let the game team to insert data without using the ini file directly.

    A graphic wants to design, not to spend time wriniting ini files to test animations and so on.
    When I build a new game, I want a base framework that supports a script (I'll use angelscript with your engine) and that has templates (like "Platform game template") that handles all base features of the game and inside the editor I can insert contents and test the game in the orx control.

    In that way, as soon as the graphic man can give me sprites, I can build 90% of the game in few hours. Of course the scripts has to be implemented in native code to speedup, but in this way I can see how the game is.

    Of course...that's the "dream"...the reality is that now I modified a little part of orx to permit integration with an external message pump and i'm redirecting the console. When done i'll try to embed the orx window into a control and check for side-effects.

    Bye
  • edited September 2011
    Huston...we got it!

    Now I have to fix the sizing issues and camera placement.
    .NET users, i'm so sorry...that's done in MFC and I think it's more convenient (for me of course) to keep it in MFC.

    I'll try to decouple the logic of the editor from the View in order to help future (if any) porting to other platforms.

    For now I keep experimenting and when I will get something working I release sources.

    Bye first_version.png
  • edited September 2011
    Nice!

    I'm pretty sure that if some people want to make a port at some point, they won't have too much trouble going from MFC to WxWidgets.

    Looking forward to seeing the next steps. :)
  • edited September 2011
    I used WxWidgets long time agowhen it was named WxWindows but after that experience I didn't have any occasion to use it.
    I don't want to loose time learning too much new things in the same time because that could lead to unconcluded software.

    While editing the control I've found that the best thing allow orx window embedding would be to modify the createWindow function in glfw. In one of the structures the function uses as parameter, it could be added a parameter telling that the window must be a child
    and an handle to the parent window.
    I did not modify it because I want to avoid touching the orx library creating a branch dedicated to editors.
    As of now I tried with api hooking of CreateWindowExA but for some damn reason it did not work.
    Since I don't have so much time, I took the EnumWindow way to find the orx window and attach it.

    A good improvement that orx could do one day is try to go multi-instance.
    I mean that it would be nice to enclose all static/global variables into a container structure and allow multiple instances of the engine. It could be used by editors to create more controls with different purposes (anim preview, level preview, gui editor, and so on...).
    That would be only for mac, win32 and linux versions of course.

    As of now I'm analyzing the layout of the editor and the way to use the ini files.

    bye bye
  • edited September 2011
    Hey ainvar,
    that looks really promising. I hope you have time to work on it. I am not a MFC guy, so I won't be able to help.
  • edited September 2011
    While editing the control I've found that the best thing allow orx window embedding would be to modify the createWindow function in glfw. In one of the structures the function uses as parameter, it could be added a parameter telling that the window must be a child
    and an handle to the parent window.
    I did not modify it because I want to avoid touching the orx library creating a branch dedicated to editors.

    I think it'd be totally fine to integrate such a change in the main branch.
    As of now I tried with api hooking of CreateWindowExA but for some damn reason it did not work.
    Since I don't have so much time, I took the EnumWindow way to find the orx window and attach it.

    I'm afraid I can't help you with that. I've no knowledge in MFC whatsoever.
    A good improvement that orx could do one day is try to go multi-instance.
    I mean that it would be nice to enclose all static/global variables into a container structure and allow multiple instances of the engine. It could be used by editors to create more controls with different purposes (anim preview, level preview, gui editor, and so on...).
    That would be only for mac, win32 and linux versions of course.

    Mmh I think I see what you want to do, but in this case why not simply using multiple viewports instead? No need to duplicate all the control structures to display different things at once.
    As of now I'm analyzing the layout of the editor and the way to use the ini files.

    bye bye

    Can't wait to see it. =)
  • edited September 2011
    @Peso:

    No problem, less help = more time but the editor is something I see as mandatory if more peole are working on a "big" game and those people are not IT geeks.
    In few works, it's something I feel I need so I have to complete it.
    This week end my gf is out for a fair so...I have 2 days of complete coding to implement the gui to edit the 278 parameters of orx ini files :)

    @iarwain:

    I think I will not touch orx if I can find a way to avoid it. But if I touch it I'll give you the code to discuss if modifications are needed and if they fits the orx coding concepts.

    Multiple viewports?...yes, it could work but what I would is a bit different. For me, the best goal would be to have more separare orx controls placed in different windows.
    For example I could have a main orx control to show the scene and place elements and an other second in the animation editor that shows the animation with a play/stop button.

    So I have some question about orx viewport management:

    The main scene is made of layers objects like in photoshop. That's because it would be nice to have smoething like "background layer", "layer of the land pieces", "layer of pickable objects", "layer of breakable objects", and so on...
    After selecting a layer, all objects in that layer can be selected, removed and so on.
    What's the best way to select an item with the mouse?
    Is there an event that can be used to receive the object instance under the mouse pointer?
    If not, should I check for the area of each object and test it with the mouse coords?
    For multiple selection I need to draw a semi-transparent rectangle and mark items that are selected.
    What's the best method to draw the mark and the rectangle? Scaling an image with 50% alpha would work but would be ugly to see if the image has borders.
    May be I can use 3x3 px image made od solid color and stretch it without loosing time with tinsels :)

    that's all for now.

    Bye bye
  • edited September 2011
    ainvar wrote:
    @iarwain:
    Multiple viewports?...yes, it could work but what I would is a bit different. For me, the best goal would be to have more separare orx controls placed in different windows.
    For example I could have a main orx control to show the scene and place elements and an other second in the animation editor that shows the animation with a play/stop button.

    I totally understand, and I guess that shouldn't be too hard to achieve but some plugin dependencies might not work like this. I guess you also have the option of starting more than one process.
    You also have the option of not using the surface created by orx but only use orx for rendering to multiple video surfaces (OpenGL textures) and use their content to update your actual visible surface in your editor.
    So I have some question about orx viewport management:

    The main scene is made of layers objects like in photoshop. That's because it would be nice to have smoething like "background layer", "layer of the land pieces", "layer of pickable objects", "layer of breakable objects", and so on...
    After selecting a layer, all objects in that layer can be selected, removed and so on.

    I took the same approach with Scroll/ScrollEd, the level editor I wrote for orx.
    What's the best way to select an item with the mouse?
    Is there an event that can be used to receive the object instance under the mouse pointer?

    There no automated event that does such thing but you can create a user event that does that. To get an object under the mouse cursor, you need to call two functions.
    First orxRender_GetWorldPosition(), that will transform the mouse's screen position into world coordinates and return orxFALSE if the mouse is actually not above any viewport.
    Then, using that coordinate, you can call orxObject_Pick(). The Z coordinate is used by that function: any object with a Z < at the one you pass to the function won't get considered. If more than one object are found under the position, the one with the closest Z will be returned.
    There's an alternate version, orxObject_BoxPick() that does the same thing but using a box instead of a point.
    If you want to be pixel perfect, you'll have to test for the actual pixel value of your object at that precise coordinate as the function only tests for the bounding box of objects.

    You have a very simple example in code/demo/orxBounce.c.
    If not, should I check for the area of each object and test it with the mouse coords?
    You need the world coordinate (which also depends on the aspect ratio and the size of viewports), but with the two above functions you won't need to do that manually.
    For multiple selection I need to draw a semi-transparent rectangle and mark items that are selected.
    What's the best method to draw the mark and the rectangle?

    If you want a full rectangle, I'd use a dummy object that has the special texture called 'pixel' in its graphic and scale it appropriately. If you want to write only the perimeter, you can listen to the orxEVENT_TYPE_RENDER for ID = orxRENDER_EVENT_OBJECT_END and when it's your concerned object you can directly issue drawing instruction from the orxDisplay module. That's very similar to how I display the runtime profiler on screen, btw.
    Scaling an image with 50% alpha would work but would be ugly to see if the image has borders.
    May be I can use 3x3 px image made od solid color and stretch it without loosing time with tinsels :)

    I think the two above methods should do the trick, but yes, you can do whichever is easier for you. You can also procedurally create/modify textures on the fly, no need to have them all coming from a file if you don't want that dependency.

    Last option: using a shader that you attach to your selected objects on the fly at that will do whatever you want. The shader code can be defined in config. I use this kind of technique for drawing the infinite grid in ScrollEd.
    that's all for now.

    Bye bye

    Cheers, have fun and don't hesitate if you have any other question. :)
  • edited September 2011
    Hi all,

    I'm still here and I'm writing just to inform you (the community) that:

    -I've found a way to embed the orx window into an mfc app (you know that).

    -As iarwain indirectly suggested, I've found a way to embed the orx window into a C# .NET app.

    -I'm using orx directly from a C# .NET app because I made all 900 DllImport (not fully implemented yet).

    -I've found the way to anchor and resize the orx window like a common control.

    -I'm going to start with the gui of the editor for orx contents.

    As soon as I get something to show I'll post here code/samples and screenshots.

    @iarwain:
    I think I have a pair of modifications to the orx sources to submit to your attention in order to make thinks easier for people that wants to use .NET with orx.dll.
    Can we discuss it here (to see if anybody else have suggestions) or it's better to open a new thread?

    Bye bye
  • edited September 2011
    ainvar wrote:
    Hi all,

    I'm still here and I'm writing just to inform you (the community) that:

    -I've found a way to embed the orx window into an mfc app (you know that).

    -As iarwain indirectly suggested, I've found a way to embed the orx window into a C# .NET app.

    -I'm using orx directly from a C# .NET app because I made all 900 DllImport (not fully implemented yet).

    -I've found the way to anchor and resize the orx window like a common control.

    -I'm going to start with the gui of the editor for orx contents.

    As soon as I get something to show I'll post here code/samples and screenshots.

    Nice work! Noob question: wouldn't it be possible to compile a managed C++ version of orx (and adapting some modules such as memory allocation) to easily use with any .NET language, and potentially be a first step toward Xbox support?
    @iarwain:
    I think I have a pair of modifications to the orx sources to submit to your attention in order to make thinks easier for people that wants to use .NET with orx.dll.
    Can we discuss it here (to see if anybody else have suggestions) or it's better to open a new thread?

    Bye bye

    Either way is fine by me!
  • edited September 2011
    iarwain wrote:
    Nice work! Noob question: wouldn't it be possible to compile a managed C++ version of orx (and adapting some modules such as memory allocation) to easily use with any .NET language, and potentially be a first step toward Xbox support?

    Is there an emoticon with the face of "The Scream" by Munch?

    Yes, I think it could be possible but all depends on what you mean with "to easily use with any .NET language".

    In .NET you have only "safe" stuff and "unsafe" stuff.
    With "safe" we mean managed, no pointers, etc...
    With "unsafe" we mean un-managed, pointers and other error-prone stuff that oldschool coders like more.
    The entire architecture of orx, for example, is...well...unsafe...completely unsafe!

    All non-assembly (assembly in .net is a managed dll) dll's are unsafe and to access them from C# or VB.net you have to use a directive (that's DllImport) and re-declare all signatures of the functions you wanna import in a .net comestible way.
    Even data structures needs to be re-declared and you don't have support for unions (that's a part of the thinks I'm goind to discuss about orx modifications).

    The C++.net is a bit more flexible.
    You can link the dll as in a common c++ app, but you can't access imported functions directly from "safe" functions.
    In other words, you need to write a "safe<->unsafe" wrapper.

    I've done the C# way (DllImport) because my goal is to write the editor and start developing my games asap.
    With the orx wiki pages, codewright and some macro i've built the imports in 2/3 hours and with C# I'm more productive than managed c++.

    I don't know the XBox dev. env. so I don't know why you want to modify the orx code.
    If the XBox platforms allows unsafe code to run I think we have all we need...if not I think we have to rewrite a lot of stuff in orx to recompile it as a "safe" .net library.
  • edited September 2011
    Thanks for all the precisions.

    I don't know the precise requirements for publishing on XBLIG/XBLA and I'm personally not interested by that aspect. I simply assumed a plain malloc/dlmalloc would probably not let you pass the TRCs.

    Alastriona began to wrap orx for .NET. The branch's still there and probably largely outdated. If you're curious you can have a look at it: https://orx.svn.sourceforge.net/svnroot/orx/branches/mORX/
  • edited September 2011
    Small addendum:
    I know for sure that native C/C++ code is allowed on XBox using the XDK for approved developers as I've done that for years.
    However I don't know if unsafe code is allowed for XBLA/XBLIG markets using the XNA framework available for indies.
  • edited September 2011
    I'm sorry, I've never developed for xbox so I don't know anything about policies they are adopting.

    I took a look ar morx. Yes, it seems outdated and incomplete but it's a good starting point for future developments.

    For now all I want is to let artists to fill my ini files without writing a single ini section and to be able to preview all animations and levels before writing a single line of code.
    When i'll reach this goal, i can think about the rest :)
  • edited September 2011
    Definitely. I was merely mentioning it for exhaustiveness' sake. :)
  • edited October 2011
    Hi iarwain

    I have a problem with resizing.

    When I load the application and I start the Orx engine, I "capture" the window an force it to be child of my control. That's works, even if I'd prefer a API hook way (but it does not work :( ).

    After child-ing the orx window I used a c# translated version of gray's tutorial and so:

    orxControl.CurrentViewport = OrxNative.orxViewport_CreateFromConfig("Viewport");
    OrxNative.orxSTATUS st = OrxNative.orxConfig_Load("StaticScene.ini");
    IntPtr obj = OrxNative.orxObject_CreateFromConfig("Scene");

    Since I've set orxControl anchors, when I resize the main window I resize the orxControl and it's child (the orx original window).
    The OOW (original orx window) has a relative position of 0,0 and variable width and height.

    After loading the viewport, camera and scene, It's diplayed but as soon as I resize the window, the scene moves as it had a bottom-left anchor.
    I mean if i resize using the main window left resize-handles, and i reduce the size moving the mouse to the right, the entire scene moves to right, disappearing on the right border of the OOW.

    What I want id to maintain my scene at the center.
    How?
  • edited October 2011
    I don't understand the problem.
    In GLFW there's a function to modify the size of the window. It's _glfwPlatformSetWindowSize and is an internal function and it does the same things I'm doing to modify the window.
    It is called by glfwSetWindowSize.

    What is missing is a call from the plugin.
    The similar function glfwGetWindowSize is called by orxDisplay_GLFW_SetVideoMode.

    I'd like to modify plugin functions in order to pass a HWND as parent for the created window. This value could be an unsigned int64 (64 bit ready) that will be used only by plugins that knows it's meaning.
    In this way I can avoid to "capture" the orx window in the way I'm doing now.

    Then I'd like to add a orxDisplay_SetWindowSize that updated all variables needed to avoid clipping. Now the resized window clips the viewport.

    Do you have suggestions? I tried to add a plugin function but with no luck.
    Later I'll try to spend more time on this.
  • edited October 2011
    As you found out there's not support for resizing a window with orx right now. That means you need to call orxDisplay_SetVideoMode() with the new settings and this will delete and create a new window, which is definitely troublesome in your case.
    The second problem is that the viewport needs to have its size updated to that the rendering is adapted to the new window. This is pretty easy and you have all the accessors you need in the viewport module.
    I'll look into adding resize support. I know I'll have to recreate the GL texture associated with the screen at the right size but I also need to look at the code in GLFW to see if there's any GL context re-creation going on. If so, I'll need to backup/restore all the textures/shaders as it's done in the SetVideoMode() function.
    I'll also need to make sure the SFML & SDL plugin will compile but I don't think I'll support that feature for now in the associated plugins.
  • edited October 2011
    iarwain wrote:
    As you found out there's not support for resizing a window with orx right now. That means you need to call orxDisplay_SetVideoMode() with the new settings and this will delete and create a new window, which is definitely troublesome in your case.

    I discovered that the first time I tried to change the video mode :)
    As of now I implemented a orxDisplay_SetWindowSize into the GLFW module and it's working. It just calls glfwSetWindowSize.
    The second problem is that the viewport needs to have its size updated to that the rendering is adapted to the new window. This is pretty easy and you have all the accessors you need in the viewport module.

    I tried to modify the viewport according to the size of the orx window.
    I can place it inside the orx window but the problem is that it's contents are clipped by what seems to be an invisible window linked to the bottom left of the orx window.
    For example i have a orx window of 1024x768 and I place a 800x600 viewport in the middle od the orx window.
    I can move the viewport up/down/left/right and it's contents are alway in the same relative place.
    If I change the orx window size to a 1024x1200 using the bottom resize handle, I see contents in the viewport moving and disappearing into the bottom edge of the viewport.
    If I reduce the dimension, the contents of the viewports diappear at some point...but not the top edge of the viewport.
    Contents are clipped in the middle of the viewport.
    I'll look into adding resize support. I know I'll have to recreate the GL texture associated with the screen at the right size but I also need to look at the code in GLFW to see if there's any GL context re-creation going on. If so, I'll need to backup/restore all the textures/shaders as it's done in the SetVideoMode() function.
    I'll also need to make sure the SFML & SDL plugin will compile but I don't think I'll support that feature for now in the associated plugins.

    I try to find a good way to pass a handle to the window creation function so I'll stop "capturing" the window in such strongly platform dependant way and we can do the same on other platforms.
  • edited October 2011
    ainvar wrote:
    I discovered that the first time I tried to change the video mode :)
    As of now I implemented a orxDisplay_SetWindowSize into the GLFW module and it's working. It just calls glfwSetWindowSize.

    Don't forget to update the plugin's internal metrics (in sstDisplay) otherwise it's unlikely that rendering will happen at the right position.
    I try to find a good way to pass a handle to the window creation function so I'll stop "capturing" the window in such strongly platform dependant way and we can do the same on other platforms.

    One of the easiest solution would be to store it in config in the Display section and read its value there from the GLFW display plugin.
  • edited October 2011
    Basically here's what i've done:

    orxSTATUS orxFASTCALL orxDisplay_GLFW_SetScreenSize(orxFLOAT _fWidth, orxFLOAT _fHeight)
    {
    orxSTATUS eResult = orxSTATUS_SUCCESS;

    /* Checks */
    orxASSERT((sstDisplay.u32Flags & orxDISPLAY_KU32_STATIC_FLAG_READY) == orxDISPLAY_KU32_STATIC_FLAG_READY);

    /* Gets size */
    sstDisplay.pstScreen->fWidth = _fWidth;
    sstDisplay.pstScreen->fHeight = _fHeight;

    glfwSetWindowSize((int)_fWidth, (int)_fHeight);

    /* Done! */
    return eResult;
    }

    And then added all entries for plugin handling.
    I guess that's not enought because of things you said about the gl texture to recreate.
    As of now I keep this version of the function waiting for your version, because I'm not an opengl geek and there's a lot of stuff to complete for the editor.
    I leave you with a little screenshot of the editor:

    Since it's "an orx contents editor" (an o.c.e.) i named it Ocean.

    Ocean.png
    Ocean 34.9K
  • edited October 2011
    I'll try to do the resize tonight. I'll probably simply update the SetVideoMode() to do a resize when both modes are windowed.

    Ocean looks promising. I like the name too! :)

    EDIT: And add a AllowResize mode (+events) so that users can use the windows handle to resize.
  • edited October 2011
    iarwain wrote:
    I'll try to do the resize tonight. I'll probably simply update the SetVideoMode() to do a resize when both modes are windowed.

    Ocean looks promising. I like the name too! :)

    EDIT: And add a AllowResize mode (+events) so that users can use the windows handle to resize.


    %YOUR_FAVORITE_DIVINITY% bless you!

    Tell me when you have any news and I'll test asap. If you need an Ocean WIP release to test with your code I can send you but there are other 2 mods you need to implement before running the Ocean editor.
    The first is to add 3 inline functions into orx.h.
    They are needed to update orx engine from an application message pump. Another way would be to process messages when receiving events from orx but I like to have more oppotunities :)
    /** Orx main execution function initialization
    * @param[in] _u32NbParams Main function parameters number (argc)
    * @param[in] _azParams Main function parameter list (argv)
    * @param[in] _pfnInit Main init function (should init all the main stuff and register the main event handler to override the default one)
    * @param[in] _pfnRun Main run function (will be called once per frame, should return orxSTATUS_SUCCESS to continue processing)
    * @param[in] _pfnExit Main exit function (should clean all the main stuff)
    */
    static orxINLINE orxSTATUS orx_Execute_Init(orxU32 _u32NbParams, orxSTRING _azParams[], const orxMODULE_INIT_FUNCTION _pfnInit, const orxMODULE_RUN_FUNCTION _pfnRun, const orxMODULE_EXIT_FUNCTION _pfnExit)
    {
    /* Inits the Debug System */
    orxDEBUG_INIT();

    /* Checks */
    orxASSERT(_u32NbParams > 0);
    orxASSERT(_azParams != orxNULL);
    orxASSERT(_pfnRun != orxNULL);

    /* Registers main module */
    orxModule_Register(orxMODULE_ID_MAIN, orx_MainSetup, _pfnInit, _pfnExit);

    /* Registers all other modules */
    orxModule_RegisterAll();

    /* Calls all modules setup */
    orxModule_SetupAll();

    /* Sends the command line arguments to orxParam module */
    if(orxParam_SetArgs(_u32NbParams, _azParams) == orxSTATUS_FAILURE)
    return orxSTATUS_FAILURE;

    /* Inits the engine */
    if(orxModule_Init(orxMODULE_ID_MAIN) == orxSTATUS_FAILURE)
    {
    /* Exits from all modules */
    orxModule_ExitAll();
    /* Exits from the Debug system */
    orxDEBUG_EXIT();
    return orxSTATUS_FAILURE;
    }

    /* Registers default event handler */
    orxEvent_AddHandler(orxEVENT_TYPE_SYSTEM, orx_DefaultEventHandler);

    /* Displays help */
    if(orxParam_DisplayHelp() == orxSTATUS_FAILURE)
    {
    /* Removes event handler */
    orxEvent_RemoveHandler(orxEVENT_TYPE_SYSTEM, orx_DefaultEventHandler);
    /* Exits from the Debug system */
    orxDEBUG_EXIT();
    return orxSTATUS_FAILURE;
    }

    return orxSTATUS_SUCCESS;
    }

    /** Orx main execution function step
    * @param[in] _pfnRun Main run function (will be called once per frame, should return orxSTATUS_SUCCESS to continue processing)
    */
    static orxINLINE orxSTATUS orx_Execute_Step(const orxMODULE_RUN_FUNCTION _pfnRun)
    {
    orxSYSTEM_EVENT_PAYLOAD stPayload;
    orxSTATUS eClockStatus = orxSTATUS_SUCCESS;
    orxSTATUS eMainStatus = orxSTATUS_SUCCESS;

    /* Clears payload */
    orxMemory_Zero(&stPayload, sizeof(orxSYSTEM_EVENT_PAYLOAD));

    /* Main loop */
    if(sbStopByEvent == orxFALSE)
    {
    /* Sends frame start event */
    orxEVENT_SEND(orxEVENT_TYPE_SYSTEM, orxSYSTEM_EVENT_GAME_LOOP_START, orxNULL, orxNULL, &stPayload);
    /* Runs the engine */
    eMainStatus = _pfnRun();
    /* Updates clock system */
    eClockStatus = orxClock_Update();
    /* Sends frame stop event */
    orxEVENT_SEND(orxEVENT_TYPE_SYSTEM, orxSYSTEM_EVENT_GAME_LOOP_STOP, orxNULL, orxNULL, &stPayload);
    /* Updates frame counter */
    stPayload.u32FrameCounter++;
    }

    if ((eMainStatus != orxSTATUS_SUCCESS) || (eClockStatus != orxSTATUS_SUCCESS) || (sbStopByEvent == orxTRUE))
    return orxSTATUS_FAILURE;
    return orxSTATUS_SUCCESS;
    }

    /** Orx main execution function stopper
    */
    static orxINLINE void orx_Execute_Stop()
    {
    /* Removes event handler */
    orxEvent_RemoveHandler(orxEVENT_TYPE_SYSTEM, orx_DefaultEventHandler);
    /* Exits from engine */
    orxModule_Exit(orxMODULE_ID_MAIN);
    /* Exits from all modules */
    orxModule_ExitAll();
    /* Exits from the Debug system */
    orxDEBUG_EXIT();
    }


    Another mod I've done is to add a new compiler flag to change the orxFASTCALL define. The .Net DllImport directive works only with cdecl and stdcall so that's what I've done at line 198 of orxDecl:
    #if defined(__orxFREEBASIC__)

    #define orxFASTCALL __stdcall

    #else /* __orxFREEBASIC__ */

    #if defined(__orx_FASTCALL_AS_STDCALL__)

    #define orxFASTCALL __cdecl

    #else

    #define orxFASTCALL __fastcall

    #endif

    #endif /* __orxFREEBASIC__ */

    In this way I can keep a consistent INLINE define and use the cdecl to import into .net.


    If you (iarwain & the community) have any suggestions...well, they are well accepted :)
  • edited October 2011
    ainvar wrote:
    Tell me when you have any news and I'll test asap. If you need an Ocean WIP release to test with your code I can send you but there are other 2 mods you need to implement before running the Ocean editor.

    Unfortunately I fell asleep before touching the computer last night so I might not have the opportunity to do it before Sunday now (my older daughter's birthday is coming at the end of the week and there are many things left to be done before then).

    I'll be happy to try the WIP of Ocean.
    The first is to add 3 inline functions into orx.h.
    They are needed to update orx engine from an application message pump. Another way would be to process messages when receiving events from orx but I like to have more oppotunities :)

    Mmh, I'm not sure I fully understand that but I guess I'll understand it more when looking at your code. By the way, everything in orx.h is optional. Those are only helpers so feel free to write your own loop/sequencing on your side, no need to add it to orx.h.
    Another mod I've done is to add a new compiler flag to change the orxFASTCALL define. The .Net DllImport directive works only with cdecl and stdcall so that's what I've done at line 198 of orxDecl:
    #if defined(__orxFREEBASIC__)

    #define orxFASTCALL __stdcall

    #else /* __orxFREEBASIC__ */

    #if defined(__orx_FASTCALL_AS_STDCALL__)

    #define orxFASTCALL __cdecl

    #else

    #define orxFASTCALL __fastcall

    #endif

    #endif /* __orxFREEBASIC__ */

    In this way I can keep a consistent INLINE define and use the cdecl to import into .net.

    I have a question about this one, wouldn't it better to have a __orxDOTNET__ instead, in which you can do all the adjustments you need? Also currently your define's name is misleading: you're using cdecl and not stdcall as the name is suggesting. :)
    I don't know the requirements for DllImport, but cdecl will generate a bigger/slower code than stdcall. It probably doesn't matter much for an editor but I thought I'd point it out. :)
    If you (iarwain & the community) have any suggestions...well, they are well accepted :)

    I just did! ;)

    I'll let you know when I get the time to do the resize.
  • edited October 2011
    sure I'm wrong with stdcall instead of cdecl in naming the define...well...after few tests I forgot to check the name. :)

    Yes, maybe you're right about the define name but:

    orxFAST_CALL_AS_CDECL means the user must know what his language needs and make proper choices.
    orxDOTNET meand orx must know about the existence of .net.

    For me is the same, the only .net limitation i see is about the call conventions.
    I know cdecl is slower, but as you said, on an editor and on a fast pc no-one will notice that :)

    So happy birthday to your daughter. I have so many things to make that I can live without resizing for a while :) I still have to implement editors for all animations, graphics, bodies and so on...

    bye bye
Sign In or Register to comment.