Jump to content

TheoLogic

Members
  • Posts

    142
  • Joined

  • Last visited

Everything posted by TheoLogic

  1. TheoLogic

    PS3

    C# isn't cross platform . But I agree, as far as functional requirements, C# can do almost (except for hardware handling) everything C++ can do. The main difference is how you do it. C# doesn't offer machine performance. Don't go and tell me it does, because it doesn't at all: I'm almost shipping a game for WP7 (XNA), which I have previously released for Nintendo DSi (C++). The lower end DSi is faster (same game logic) as the WP7 version. I had to do some caching and GC trickery to avoid lag while ingame.
  2. TheoLogic

    PS3

    IPhone development is free, publishing not . Same as Android and WP7 tbh. XBox idd has XNA, which is better as nothing at all. It's fairly easier to get a XBox dev license than PS or Nintendo...
  3. Those sound useful, but you can achieve most of them in VS... Building different sources in different build modes is I personally think in general a very bad idea. This is pretty error prone, and you can mix up those settings really quickly. I prefer building libs, and linking the lib I need for the build configuration I need. Syntax highlighting workaround would be visual assist, combined with the default IDE Tools -> fonts and colors. Intellisense is indeed a tad slow, much better in VS2010 with the light SQL DB. Much better results again with visual assist. You are stuck with the DB file, I admit. On the other hand, things I use every minute I code: - Cut/Copy/paste whole line - Open header/cpp (va) - Create implementation (va) - Add include (va) - ... can not be done in code::blocks. But again, this all depends on the user .
  4. You can optimize VS build speed, but the main reason why it's slower would be the optimizations. If you take a look at the VS STL you will see a lot of meta template programming, which will take extra compile time. On the other hand: the time you win while compiling, you will loose with the IDE. VS has a bunch of features, shortkeys, plugins, ... Saving you more are the seconds when compiling . But again, all comes down with what you feel good with. If you prefer code::blocks, just use it, use notepad if you like! The main thing is to get the job done, how you do it doesn't really matter that much.
  5. I'm not trying to sell you C++ . But if you say C get's the job done faster, in 75% of the cases I will not agree. In C you just need to get everything right to keep the compiler satisfied. Doing this, even when you have reusable code, you still miss some constructs like a red-black tree or hash tables, dynamic arrays, ... Constructing those from scratch in a real pain in the bum. I do agree that if you don't know C++, and some other language, you will probably get there faster .
  6. Interesting, I never heard about OOC but it seems it looks a lot like C++. I should tell you to take a look at the STL. A lot of the template magic and meta programming has been done for you, no need to reinvent those things. I do not however agree that you must use templates in C++. C++ supports templates, and is useful for generic development, but 95% of my code involves no templates at all (at least not directly, for example by using the STL). With the upcoming, almost completed new ISO standard, you get new algorithms, containers, smart pointers logic, variadic templates, initializer list, ... where the biggest performance booster would be rvalue references empowering move semantics and perfect forwarding. Even if you do not plan to use this, I would suggest to take a look at it, you can find some very interesting design patterns there. Targeting professionals on 64bit is as clear as the answer to my question can get .
  7. Hello Guy, just out of interest, why C, and why (only) 64bit?
  8. I remember the time we used LWE for our school project... Just contact your school's administration, Josh supported this very well!
  9. There are some things that will not work as expected: if(States.empty() != NULL) Wait whut? If bool != 0? Which warning level are you compiling at. This should warn for conversion. Let's say .empty() returns true, you will do if(true != false), else if(false != false)... The check should be: if(States.empty() == false) Another thing would be the back() and pop_back() calls. pop_back returns the element, so you can just pop_back()->Destroy() it. Isn't this leaking? State is a pointer, what does Destroy do? What IDE are you using? A possible problem could be if you're using prior to VS2010, that you build the lib in SCL and the test-project (or whatever you name it) in HDI (debug vs release). What actually happens here is that the sizes of vector aren't the same, so hence an error.
  10. TheoLogic

    Louie, Lua

    NOTE: I should use wstrings for the game oriented commands. French people (and others) will not be happy with the multibyte character set .
  11. TheoLogic

    Code::Blocks

    - You can optimize VS build times (link). - MinGW runtime is embedded in the executable, you can achieve the same with static linking in VS. - VS2010 lite SQL intellisense is way better as in VS2008. I see no obvious plus points in code::blocks. - VS2010 can stop build on first error with some IDE macro, already implemented in some extensions. - VC++ optimizer is one of the best on the market! Even the MS STL optimizations are a blast (funcky meta-programming), that's why compiling takes a tad longer . This is my overall opinion, not LE2 related. VS beats every other IDE in easy of use (personal opinion)!
  12. Looking good. I once challenged me to try to recreate the ZBrush UI, a real inspiration . I didn't got far... As for a black theme, I think that isn't a must. Most of your window will be scene (I guess). In 3DsMax, everywhere you look you see GUI. In that case black theme, or let's say dark theme is a good idea.
  13. TheoLogic

    iWerks

    Damn, I want one (or two) of those . One day you'll hate XCode, objective C and would wish you could use Visual Studio. If I develop for mac, I code in Visual studio, commit to svn, and update on mac, just because XCode misses all basic development actions and a good window layout. I think I must not say there are no good graphical svn clients (free) for mac, so command line is the way to go... You can customize everything in visual studio, from compiler and linkers, to revision handling etc. Combined with Visual Assist for C++ and Resharper for C# no other IDE can compete. I think it's (little) mistake to say Mac is more like Linux than Windows is. Mac has objective C, one of a kind. Maybe good to know is that steam mac sales are below charts. I know 3 indie companies who ported for mac, and launched at the release date, and still now they haven't got sufficient revenue to cover the port. Everyone is going to think I'm a mac hater, and in a way I am. I love it for graphical work, but for daily use and development it's really not my preference. Good to hear you're making progress! I have some spare time soon, and I'm thinking to make a test case for performance, to see if we can actually create a game with good looking graphics and gameplay. @Lumooja: About Havok. I've talked with Steve Ewart from Havok at GDC 2010, and have seen crazy progress and things yet to come. Now that intel is in charge they really have very high goals!
  14. Indeed, where did you follow this?
  15. @Roland: Your proposition seems like the way to go. Don't forget the virtual destructor though .
  16. @Lazlo: If Josh wants to use LWE on a wide variety of platform he won't use try-catch error handling (Nintendo ao.). @Rick: Buffer* b = new OpenGLBuffer; (without brackets, brackets mean a function. It is valid C++, but not so clean code.) And I see a lot of assignment overhead... Shader* myShader = pFactory->CreateShader(); (sorry Roland, I just copied it from you because it's on this page ). = a constructor + assignment. Shader* myShader(pFactory->CreateShader()); = only constructor. I know in most cases you really won't see the difference. But all bits help in game performance...
  17. This is not my first try to implement multithreading with LWE, and I must say calling engine commands in different threads == fail! I solved it by using queue's to stash update data and updating it in the main loop. Yes I know, this is a wonderful person to handle. For animated loadingscreen I used windows GDI, a lame and unsafe hack. That the reason why leadwerks should have a render and an update thread...
  18. Combine the power of C++ with some optimization and this is what you get. There are two problems with this: 1) Most of the time ppl just use the wrong container, method, ... to do things. How often do I hear someone using STL lists where a simple vector would do, or use algorithms to handle a container while the container has method to handle the same thing! The most ridiculous thing I ever heard were people wanting to write their own "vector container" because it didn't had a method they needed, which could be done with a for_each loop. 2) Some people reading optimization tips say: "hell, I didn't do this, let me change that". This often results in minimal performance gain, and total unreadable code. Premature optimization is the root of all evil!!! You should write your code until it works, profile it and handle bottleneck by bottleneck. I once remember we profiled some educational engine, and the most used method taking the most CPU time was an Exists() method of the bitmap class. But again, this only took 1% of the total CPU time, most was drawn inside windows' GDI rendering. C++ isn't easy, you need to do everything by hand. Yes you need to write your own assignment operator and copy constructor or disable them if you don't need them, yes you need to encapsulate, yes you need to check for memory leaks, yes, yes, yes... What I often do with some code that is really important, like for example resource handling, is writing my code until it works, let it rest one or two days and take a look at it again. This takes time, so I don't afford to do this for everything. But I must say it helps in my case.
  19. @Rick: remember farcry 2? Foliage flying around, fire sparkles everywhere... For things like that you need the stack. I would like to see C# or java handle that, creating memory on heap for every little effects that lasts 2-5 seconds.
  20. @Lumooja, pointers aren't old C++, they are C++. C++ gives you the power to decide which memory you want to use, stack or heap. I would like to see how STL could replace pointers? They have smart pointers which you don't want to use, but STL is for data management. I agree on using boost, I'm still waiting until it's STL standard!
  21. To get this smoothed out use Curve. Now you are using some linear movement, if you want some swifty side movement you'll need to use some math.
  22. Havok is like Josh says pretty rough... It's used in 3ds Max, and I must say 3rd party libraries using PhysX do the job way better. I must agree it would be nice to see PhysX in Lwe.
  23. Depending on placement, between 10 and 20 cm...
  24. The result is better if I lower the iterations for the update, but this leads me to being able to pass walls on indoor scenes at lower framerates...
  25. After exams I will. Just some movie from RE::Pest showing how this lags... I'm sorry, but I am on a tight schedule right now. After January I have time to document, and test if needed.
×
×
  • Create New...