Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pjcast]

We have decided to open up the Ogre Studio project (under the GPL). Partly as a gift to the Ogre community, mostly to build a build a bigger community around the project to make it a strong level/world editor for Ogre related projects.

Main Site: http://www.ogre3dstudio.com/index.html
Download Site:  http://www.ogre3dstudio.com/downloads.html

There is no current binary release; however, building is very simple after grabbing from SVN (~20 MB download) as, currently, all dependencies are setup in svn. It requires Visual Studio 2005 (it uses C# & .Net 2.0).

* The debug build is setup to run perfectly from where it builds to
* The release requires you to copy over media/setting files from the debug directory - this is because it was the easiest way to have debug & release installed applications run identically by having the media files in one place
* When you build the release target (if you have Visual Studio 2005 Standard & above) he installer project should build when you build release mode and install perfectly

Some screen shots:

Shows multiview with different settings for each window.



Squirrel script editor and remote debugger.



Custom color control.

I hope that Ogre Studio will become a valuable tool in Ogre users' toolboxes After the holidays, work will resume full force on Ogre Studio again. Until then, maybe some users might get better aqauinted with the code base :-)

Merry Christmas!!

[OvermindDL1]

SVN has a wrong certificate.

Looks nice though.  And still can't touch it due to how broken .NET2 is on this machine...  (what is wrong with native, or at most, .NET1.1?  Native is best for multi-platform, don't expect this to ever work on anything non-windows thanks to recent actions by microsoft dooming certain non-windows versions of .NET interpretors...)

[pjcast]

SVN has a wrong certificate.

Looks nice though.  And still can't touch it due to how broken .NET2 is on this machine...  (what is wrong with native, or at most, .NET1.1?  Native is best for multi-platform, don't expect this to ever work on anything non-windows thanks to recent actions by microsoft dooming certain non-windows versions of .NET interpretors...)

.Net 1.1 is like using an old broken C++ .Net has so many more features. And, I really don't share your view about it not working on multiple platforms because of actions from Microsoft.

As for why no native code, ease of development. Sure, I could spend my time writting something in C++ for GUI development, but I don't have much time.. .Net is so much faster to write GUI tools in.

About the svn cert, not sure what you mean... what error/message do you see?

[Clay]

Just ignore the cert error.  Pjcast didn't pay the absorbent amount of money to buy a signature for the cert, so it will pop that up whenever you use ssl.  I hate the verisign system.  =/

[OvermindDL1]

I am not sure what you are referring to about ease of development.  Any form generation tool I've used for anything from MFC to wxWidgets is just as easy as the one for C# (especially since it is the same one used for C++MFC).  And in gui code I am very liberal with my use of smart pointers so I have not had a memory management issue in many years.  Not to mention the huge amount of code and libraries for C++ let's me code faster without needing to reinvent things as I have to often do with other languages...  As it stands, could your app load in *nix/bsd/mac?

The svn certificate error is in regards to accessing https://www.wreckedgames.com/svn/visualogre/ and the certificate not in the certificate registry, in other words, it was generated and applied by the webhost, and not generated by verisign, so nothing is able to authenticate it.  The error comes up in firefox, opera, and the svn client.  Can just tell it to accept for the session, accept permanently, or deny in all three, tested no where else.  Easy to bypass, but sometimes the computer settings are setup to auto reject such certificates because they are commonly used to sign invalid things (spyware and so forth), so it would be good to fix it to make sure there would be no problems.

EDIT1:  Ah, clay posted after I hit reply but before I hit send (SMF tells you about that...).

Most webhost providers buy certs in bulk so they are vastly cheaper, and just part of the package.  At least the two hosts I've had has done that.  Costs me $1 extra a month for my domain, and I'm not even using it... >.>

EDIT2:  Nice details on the certificate too, definitally would not be accepted by Verisign.

Code: [Select]

www.wreckedgames.com
SomeOrganization
SomeOrganizationalUnit
SomeCity
SomeState, --
emailAddress: root@www.wreckedgames.com

[pjcast]

I'm raelly not interested in using any verisign certs. Or any other paid for certs. If you can't trust wreckedgames enough to click ok to access svn, then I don't trust that person not to still the code  :lol:

Again, I'm not debating in this thread the pros/cons of C# over other languages. Needless to say, however, you cannot even compare MFC to .Net/C#/Winforms. If you are, then I suggest you go do a small app in MFC, and the same app in Winforms to realize that is just not true As for linux, these issues have been disscuessed also. Currently, you are right (and I have never stated otherwise), Ogre Studio does not run in Linux... hopefully, it will eventually.. just a few hurdles to pass. Anyway, most people are in fact on windows right now anyway.

[Clay]

Edit:  Doh, pjcast beat me to it.

I am not sure what you are referring to about ease of development. Any form generation tool I've used for anything from MFC to wxWidgets is just as easy as the one for C# (especially since it is the same one used for C++MFC). And in gui code I am very liberal with my use of smart pointers so I have not had a memory management issue in many years. Not to mention the huge amount of code and libraries for C++ let's me code faster without needing to reinvent things as I have to often do with other languages...

This really isn't the place to have your typical C++ vs [insert managed language here] holy war.  A few very quick points:

[list=1]

• C# is an incredibly productive language beyond simply writing gui's.  It's a far more productive language than C++ in virtually all aspects (and this is coming from an experienced C++ developer).
• C#'s language features and the extensive .Net class library are the reasons for its productivity.  If you haven't played with delegates, events, properties and so on I suggest you give them a try.
• C# embraces a component based development model.  Thanks (primarily) to delegates and events, C# allows for very modularized, component based code.  This makes life a lot easier on the programmer, and ultimately makes you more productive.
  
• Automatically refactoring code...and it actually works.
• You say you use smart pointers in your GUI code and that makes you more productive...  Every "pointer" in C# is a smart pointer.  No need for extra code, or extra work to use them everywhere.  All of the reasons you use smart pointers in your C++ GUI code is already done for you in C#.
  
• Error handling/exceptions are better in C#.  Instead of getting cryptic crashes/null pointer exceptions deep within C++ code, in C# you generally get an exception telling you exactly what the problem is.[/list:o]
  
  There are other reasons, and these are only the highlights.  I'm sure you can be very productive with C++, but you will ultimately be more productive in a managed language like C# (or Python).  You pay for these nicities with other issues, such as performance and portability.
  
  

  As it stands, could your app load in *nix/bsd/mac?

  
  This is a seperate issue, and no it currently does not.  If Bekas ports Mogre to mono then it would not be difficult to get a linux/mac port going.
  
  Even in the open source community 90% of people have access to a windows machine even if they don't use it as their primary operating system.  I don't really see this as being much of an issue.  I'd love for it to run on Linux, but given the choice of writing all of this in C++ or having a Linux mac version, I'll stay with C#.

[Clay]

I've updated the site with a binary installer.  You can get it here.

[OvermindDL1]

Personally, when making a gui in C++, I use Juce.  It may have been designed for another purpose, but I have yet to see an easier way for making gui's.

Definitally does not look like an standard OS gui though, it is very much its own style...

EDIT:  It works, somewhat, not sure if it is my corruptish .NET install or what, but may as well mention them to make sure it is either me or whatever.  The fact that it runs at all is interesting since most things don't.
If I click a menu item, like File, so it pops-up, and move the mouse over to edit, the pop-up disappears, but edit's pop-up does not appear, it just seems to all reset.  If I open a file like test.nut, the text editor acts *really* odd.  None of the shortcuts work (can't do things like ctrl+z to undo).  Right-clicking does not work (no popup menu for edit/paste/etc...).  In the options box, things like the layout are not pre-selected based on what the current value is.

Honestly, I'm not sure how the .NET forms work in full, but MFC and wxWidgets and so forth, all the listed things are standard things that you have to actually work at to disable to get to how they act in this mannor.  Things like preventing the right-click in the text editor you would have to override the contextEvent on that object and return false to not have it do anything (or pop-up your own or what-not).

I'm not sure I see the point of "Exit Config" since there is an X box.  If anything, and Ok, Apply, and Cancel would be best as changing the options as they are clicked is not always wanted, sometimes things are misclicked and so forth.

When many tabs are open, the little scrolling arrows should scroll the display while it is held (as it does in VS) instead of having to click it multiple times.

The File->Recent also does not work (that is also built into MFC and so forth, I don't even know how to disable that in MFC without removing the whole Menu entry...)

[pjcast]

File recent should work. As for context menus & keyboard accelerators, there are likely some places where they are not implemented. Feel free to create bug reports on missing items - which steps to reproduce cleanly please.

As for comparing with MFC again, .Net does not do anything for you when you create forms. You are responisble for most items such as that - which is more flexible, as you can add whatever features you want instead of having to disable features you do not. Anyway as I stated, I'm not debating MFC vs .Net in this thread... If you must, feel free to start another thread in off topic forum - Ogre Studio is in .Net, and will not likely change.

[OvermindDL1]

If you have a trac up somewhere (link?) I'd be happy to start submitting detailed reports so you start to have things to mark off a list (lists are good ).  Or shall I just post them in a bug thread?  Maybe a new thread for each one?  Or I can setup a trac if you wish...

[Clay]

We use mantis for bug tracking: http://www.wreckedgames.com/mantis/

Any bug reports are much apreciated.  =)

[OvermindDL1]

Are drawing speed issues something I should add?  Or is this just not optimized yet (debug build?)?  It takes near a full second to redraw the screen when I resize it (maximise, restore, click-n-drag resize, etc...) which make dragging it to resize it... interesting (yes, I am testing how well things resize gracefully and so forth as well).

[pjcast]

Your going to have to be more specific to what slowness on resizing you are talking about... the window renderwindow, forms, the whole main window, etc. All Ogre binaries are in release build (even when Ogre Studio is in debug mode).

If you notice slight delay/hickup on the render window(s) (I see no second long delay here - and I am on sub-par hardware too), then it is just the rendering speed for the window. Change it from normal to fastest if that bothers you.

[Clay]

Performance issues are deffiantely something to add, but as pjcast said, we would need to know exactly what takes too long to redraw...