Search found 390 matches
- Mon Nov 07, 2016 2:03 pm
- Forum: Showcase
- Topic: Ogre WIP and random screenshot thread (for everyone!)
- Replies: 150
- Views: 62559
Re: Ogre WIP and random screenshot thread (for everyone!)
Damn it does look fine, even tried the demo and will be strongly tempted to buy it when it comes out. I really wanted to push openDarkEngine all the way to complete game, but I lost the wind to continue because the original source code leaked and is probably the reason we see unofficial patches that...
- Mon Oct 31, 2016 1:08 pm
- Forum: Showcase
- Topic: Ogre WIP and random screenshot thread (for everyone!)
- Replies: 150
- Views: 62559
Re: Ogre WIP and random screenshot thread (for everyone!)
Woot, got the uv coords working correctly. http://i.imgur.com/FAJrs2f.jpg Next up is objects. The levels are a bit bare without props. I'm going to pass on light maps for now. They are very low res and only 15 bit colour. I'm going to try porting to Ogre 2.1 and see how it's lighting/shadows make i...
- Thu May 22, 2014 6:08 am
- Forum: Developer talk
- Topic: A few issues
- Replies: 9
- Views: 2205
Re: A few issues
You know, this was just a cold blooded experiment if someone replies when I write something off the charts. Something has surely changed because this was not the behavior of ogre 1.4 or 1.6 (dunno about the lattter). I'll look into the problem you mention. Don't you think this should all go into som...
- Wed May 21, 2014 12:13 pm
- Forum: Developer talk
- Topic: A few issues
- Replies: 9
- Views: 2205
Re: A few issues
Is ogre essentially a dead or undermanned project now? I have to admit I am quite unhappy with the way the patch was rejected. https://bitbucket.org/sinbad/ogre/pull- ... h/activity
- Wed Apr 30, 2014 8:11 pm
- Forum: Google Summer Of Code
- Topic: [GSoC 2013 - accepted] Resource System Redesign
- Replies: 82
- Views: 42213
Re: [GSoC 2013 - accepted] Resource System Redesign
Hey,
I am really looking forward to see this in vanilla ogre - are there any plans to get this into v2-0 or is it not a viable time frame to fill?
I am really looking forward to see this in vanilla ogre - are there any plans to get this into v2-0 or is it not a viable time frame to fill?
- Wed Apr 30, 2014 8:09 pm
- Forum: Developer talk
- Topic: A few issues
- Replies: 9
- Views: 2205
Re: A few issues
Looking at v2-0 the same problem is there in OgreZip.cpp, I'd be delighted if this bug wasn't there, at least in v2-0. The doc still says: /// The file's fully qualified name String filename; /// Base filename String basename; There is no reason to have a duplicit info in the FileInfo struct, AMIRITE?
- Thu Apr 24, 2014 3:54 pm
- Forum: Developer talk
- Topic: A few issues
- Replies: 9
- Views: 2205
Re: A few issues
I've posted a pull request on the zip archive issue and will look at the cmake scripts soon.
- Wed Apr 23, 2014 2:03 pm
- Forum: Developer talk
- Topic: A few issues
- Replies: 9
- Views: 2205
Re: A few issues
Thanks for your reply, I'll report both issues as soon as I get the time to do it.
In the meantime I'll probably just clone and fix the OgreZip.cpp/.h anyway, so patch is not a problem.
In the meantime I'll probably just clone and fix the OgreZip.cpp/.h anyway, so patch is not a problem.
- Wed Apr 23, 2014 1:20 pm
- Forum: Developer talk
- Topic: A few issues
- Replies: 9
- Views: 2205
Re: A few issues
Okay, looking at the source code, there seems to be an extra branch in OgreZip.cpp load method: + else + { + info.filename = info.basename; + } This seems to have been removed in changeset 3566:047d710287b5, and got back in 4740:0adb7d41cba9 Is there any agreement on how the archive should work? fil...
- Wed Apr 23, 2014 5:29 am
- Forum: Developer talk
- Topic: A few issues
- Replies: 9
- Views: 2205
A few issues
Hey Guys, yesterday I spent my evening porting my project from ogre 1.7 to ogre 1.9 and encountered a few troubling bugs. So I'd like you to tell me I'm doing something wrong :) 1. OGRE.pc on Arch prefix=/usr exec_prefix=${prefix} libdir=${prefix}/lib includedir=${prefix}/include plugindir=${libdir}...
- Fri Mar 07, 2014 3:02 pm
- Forum: Google Summer Of Code
- Topic: [GSoC 2013 - accepted] Ogre 2.0
- Replies: 185
- Views: 81506
Re: [GSoC 2013 - accepted] Ogre 2.0
Okay, sorry for the false alarm :) I still find it alarming that the self-copy construction seems to be valid (g++ didn't even spit a warning when I tried it). EDIT: At least clang identifies the problem: a.cc:11:8: warning: variable 'a' is uninitialized when used within its own initialization [-Wun...
- Thu Mar 06, 2014 2:07 pm
- Forum: Google Summer Of Code
- Topic: [GSoC 2013 - accepted] Ogre 2.0
- Replies: 185
- Views: 81506
Re: [GSoC 2013 - accepted] Ogre 2.0
Hey,
just browsing through the commits - is this intentional?
https://bitbucket.org/sinbad/ogre/commi ... de/Grass.h
in think the vMax construction is wrong. Perhaps change:
to
just browsing through the commits - is this intentional?
https://bitbucket.org/sinbad/ogre/commi ... de/Grass.h
in think the vMax construction is wrong. Perhaps change:
Code: Select all
Vector3 vMax( -vMax );
Code: Select all
Vector3 vMax( -vMin );
- Wed Feb 06, 2013 10:58 am
- Forum: Back to Basics
- Topic: Endianness and Bitwise Operators
- Replies: 4
- Views: 1512
Re: Endianness and Bitwise Operators
While the site does not seem to contain the problem mentioned I suppose it does not hurt to mention it: http://graphics.stanford.edu/~seander/bithacks.html
- Fri Oct 19, 2012 2:58 pm
- Forum: Back to Basics
- Topic: Console design problem
- Replies: 6
- Views: 1247
Re: Console design problem
Well you can still package that and forward as the first parameter to the std::function.
Code: Select all
struct Callback {
std::function<void(Callback*, /*other params*/)> callback;
std::string name;
// etc.
};
- Thu Oct 18, 2012 12:15 pm
- Forum: Back to Basics
- Topic: Console design problem
- Replies: 6
- Views: 1247
Re: Console design problem
Personally I'd rework the console to use std::function instead and then use std::bind.
- Sat Feb 11, 2012 5:37 pm
- Forum: Developer talk
- Topic: Any support for a 'truncate' method within Vector?
- Replies: 1
- Views: 995
Re: Any support for a 'truncate' method within Vector?
Well you could do a helper function for this, skipping the need for a Vector3 method:
Code: Select all
inline void trucate(Ogre::Vector3 &v, double maxLength) {
if(v.squaredLength() > (maxLength * maxLength)) {
v = (v.normalisedCopy() * maxLength);
}
}
Code: Select all
truncate(v, maxLen);
- Sat Feb 04, 2012 6:11 pm
- Forum: Back to Basics
- Topic: Bohemia Interactive (OFP, ARMA) will use Java for scripting
- Replies: 9
- Views: 1893
Re: Bohemia Interactive (OFP, ARMA) will use Java for script
I'd be worried a bit about the fact that it is hard to control how java does garbage collection and memory management in general. JIT compiler will probably eat some resources as well (and that is not easily controllable either). I think adapting existing scripting language to LLVM could be a viable...
- Wed Jan 04, 2012 1:37 pm
- Forum: Back to Basics
- Topic: My dark auto_ptr<>
- Replies: 20
- Views: 3769
Re: My dark auto_ptr<>
I think the propper way to resolve this is to transition to 0x and use unique_ptr which does not have the hacky ownership handing c'tor and uses move semantics instead.
Edit: Oh, late to the discussion - already mentioned
Edit: Oh, late to the discussion - already mentioned

- Sun Jul 31, 2011 6:19 pm
- Forum: Showcase
- Topic: Ogre Meshy 1.6 (Mesh viewer, Windows Installer & Linux sup.)
- Replies: 257
- Views: 148901
Re: Ogre Meshy 1.21 - (Mesh viewer, Now supports Linux!)
You could try doing a coredump and analyze that instead:
Code: Select all
ulimit -c unlimited
<run ogre meshy...>
gdb -c core <ogre_meshy_binary>
- Tue Jun 07, 2011 6:12 pm
- Forum: Back to Basics
- Topic: Problem with a template function?
- Replies: 5
- Views: 1143
Re: Problem with a template function?
If you'd be working under linux, I'd tell you to try using valgrind - chances are it could find a problem (don't know about such a thing for windows). Other ideas - you're modifying the maps content whilst iterating it (in a such way it relocates/modifies the current element), the object which held ...
- Sun May 15, 2011 2:23 pm
- Forum: Back to Basics
- Topic: Accessing a vector of structs in a new thread
- Replies: 5
- Views: 961
Re: Accessing a vector of structs in a new thread
Why don't you use something like tbb::concurrent_queue? You don't have to worry about concurrency then.
- Tue May 10, 2011 6:04 pm
- Forum: Back to Basics
- Topic: Sending a struct to a class
- Replies: 9
- Views: 1065
Re: Sending a struct to a class
If you'd be still wanting to access the fields of the structs, you'd have to supply that info to the code working with the structs. I once written something similar - There was a function that was called at the beginning of the code execution (once) and mapped the fields of the struct one by one (th...
- Tue Aug 31, 2010 5:34 pm
- Forum: Feature Requests
- Topic: Atlasing addon for StaticGeometry?
- Replies: 4
- Views: 1598
Re: Atlasing addon for StaticGeometry?
After the textures are atlased how difficult is it to modify the texture co-ords of the mesh to match up? This depends on your meshes - if you have the meshes unwrapped (that is if the texturing coordinates never go out of 0-1.0f range), it is a simple thing to do. If not, this is not entirely triv...
- Mon Aug 30, 2010 12:29 pm
- Forum: Feature Requests
- Topic: Atlasing addon for StaticGeometry?
- Replies: 4
- Views: 1598
Re: Atlasing addon for StaticGeometry?
I think this is best done offline - there are probably too many "Ifs" in my opinion - the materials have to be similar (how do I compare?), the geometry has to be unwrapped, etc. The implementation itself would not be that hard to do though (meaning if your meshes/materials are prepared properly, th...
- Mon Aug 30, 2010 8:52 am
- Forum: Developer talk
- Topic: Small bug in TextureUnitState::getTextureDimensions
- Replies: 2
- Views: 747
Re: Small bug in TextureUnitState::getTextureDimensions
Sorry for the delay. The code fails in + operator of basic_string (That is used when composing the exception text). The reason is that std::vector::operator[] has undefined behavior for index out of the range 0-size() - so it gives back an invalid std::basic_string reference - in my case it is Null ...