[quote name='SteveDeFacto' timestamp='1314135264' post='4852969']
There are many many features not demonstrated in this test. Also it's loading an FBX file not a BSP file.

Yes, but that doesn't answer my question; what makes it 'next generation'?
[/quote]

The PS3 and xbox360 was refered to as the 'next generation' consoles by alot of people and even some media for over a year after their release, strictly speaking the next generation refers to unreleased future technology (Which steves engine would be since its not finished afaics) so its pretty much just another empty marketing buzzword.

Unfinished technology != future technology.

No way -- the symbol for dot product is a dot, and cross is a cross, neither are a star. If the multiply (*) operator is provided, then the only thing you should be expecting is a component-wise multiplication.
Mathematicians be damned, no graphics/games programmer should be confused by this

Could be just my experience then, I've seen funky stuff like the * operator doing cross product and the | being used for dot product (which as I pointed out, was awlays my reason to just make Cross() and Dot() funcs in those cases )

[color="#1c2837"]API has technically been in development for almost 10 years in some form or another.
[/quote]


You have a "next gen" engine that's been in development for 10 years?

[font="arial, verdana, tahoma, sans-serif"]

All of the advice you guys are giving does not add new features or speed up anything. If I worried about every little random thing that adds nothing to the project then I would never make any progress... Some of the advice ApachPiQ gave was very useful but a super majority of it served no practical function other than aesthetics.

[/font]
[font="arial, verdana, tahoma, sans-serif"] [/font]
[font="arial, verdana, tahoma, sans-serif"]You're really mistaken if you think all the advice in this thread is merely cosmetic. A lot of it will affect your compatibility, code reuse, bugs and yes, efficiency. For example, my comment on constructors and no need to zero out a class - small "aesthetic" things like that tend to have discernable performance implications, especially at such common and widely reused part of your codebase as your Vector class.[/font]
[font="arial, verdana, tahoma, sans-serif"] [/font]
[font="arial, verdana, tahoma, sans-serif"]And for the record, compatibility and [/font][font="arial, verdana, tahoma, sans-serif"](re)usability are important features of a game engine. They may not speed things up when the code runs, but they will speed up how long it takes developers to get a grasp and use your code in the future. [/font]

All of the advice you guys are giving does not add new features or speed up anything. If I worried about every little random thing that adds nothing to the project then I would never make any progress... Some of the advice ApachPiQ gave was very useful but a super majority of it served no practical function other than aesthetics.

Yes, well; welcome to 'engine dev'.

Just throwing shit together to make it work is going to land you with a badly thought out unusable mess.

You need a good, clean, well designed foundation for ANY engine if you are building from the ground up.

On the engine team here if I'm going to make a change I have to explain why, how I'm going to do it, test it on all platforms and then get the code reviewed by others on the team before I can commit it. Just making a data pipeline change had included multiple meetings of varying amounts of time with intrested parties and fellow rendering team members to ensure what is being done is sane and fits into the plan we have going forward. While you don't have to do that spending time with a design and writing clean C++ code is going to be a must (and based on what ApachPiQ said you don't have clean C++ code.. which is worrying tbh, as clean C++ isn't that hard to write and should speed up your development rather than slow it down...)

Engine development is NOT a fast thing.

Want 'fast result'? Go make a game, hack code up as much as you want to get it working.. but an engine built on that foundation? The term; unusable under performing mess springs to mind.

This is some really dirty code. That 700 lines long render function is just out of control. You should do some major refactoring before adding new features. Right now this is a model viewer at the most. Side note: Your forum is an obvious replica of the gamedev.net forums, even some descriptions unaltered, which is just unprofessional.

This is some really dirty code. That 700 lines long render function is just out of control. You should do some major refactoring before adding new features. Right now this is a model viewer at the most. Side note: Your forum is an obvious replica of the gamedev.net forums, even some descriptions unaltered, which is just unprofessional.

First how would refactoring improve performance? Secondly my forums are more of a replica of the UDK forums if we are comparing.

First how would refactoring improve performance?

Performance isn't the problem. Maintainability is the problem - start adding more features into that morass, and tracking down bugs is going to become a nightmare. A well designed architecture is your best friend, and a regular habit of refactoring is the best way to get from where you are, to where you need to be.

Besides maintainability, smart refactoring can result into less code, which can improve performance.

In your Ovgl::RenderTarget::Render() function i see two big, almost identical loops (for( DWORD i = 0; i < scene->objects.size(); i++) and for(DWORD i = 0; i < scene->props.size(); i++ )). First initiative would be to combine them into one loop so you don't have to modify both each time you make a change. If you can't combine them, put common code into functions.

Then theres stuff like


void Ovgl::RenderTarget::SetFullscreen( bool state )
{
if(state)
{
SetWindowLong(hWnd, GWL_STYLE, WS_POPUP);
RECT Rect;
GetWindowRect(hWnd, &Rect);
DEVMODE dmScreenSettings = {0};
dmScreenSettings.dmSize = sizeof(dmScreenSettings);
dmScreenSettings.dmPelsWidth = Rect.right;
dmScreenSettings.dmPelsHeight = Rect.bottom;
dmScreenSettings.dmBitsPerPel = 24;
dmScreenSettings.dmFields = DM_BITSPERPEL | DM_PELSWIDTH | DM_PELSHEIGHT;
ChangeDisplaySettings( &dmScreenSettings, CDS_FULLSCREEN );
ShowWindow( hWnd, SW_SHOW );
SetFocus(hWnd);
}
else
{
RECT Rect;
GetWindowRect(hWnd, &Rect);
DEVMODE dmScreenSettings = {0};
dmScreenSettings.dmSize = sizeof(dmScreenSettings);
dmScreenSettings.dmPelsWidth = Rect.right;
dmScreenSettings.dmPelsHeight = Rect.bottom;
dmScreenSettings.dmBitsPerPel = 32;
dmScreenSettings.dmFields = DM_BITSPERPEL | DM_PELSWIDTH | DM_PELSHEIGHT;
ChangeDisplaySettings( &dmScreenSettings, 0 );
}
}


which could be reduced to


void Ovgl::RenderTarget::SetFullscreen( bool state )
{
RECT Rect;
GetWindowRect(hWnd, &Rect);
DEVMODE dmScreenSettings = {0};
dmScreenSettings.dmSize = sizeof(dmScreenSettings);
dmScreenSettings.dmPelsWidth = Rect.right;
dmScreenSettings.dmPelsHeight = Rect.bottom;
dmScreenSettings.dmFields = DM_BITSPERPEL | DM_PELSWIDTH | DM_PELSHEIGHT;

if(state)
{
SetWindowLong(hWnd, GWL_STYLE, WS_POPUP);
dmScreenSettings.dmBitsPerPel = 24;
ChangeDisplaySettings( &dmScreenSettings, CDS_FULLSCREEN );
ShowWindow( hWnd, SW_SHOW );
SetFocus(hWnd);
}
else
{
dmScreenSettings.dmBitsPerPel = 32;
ChangeDisplaySettings( &dmScreenSettings, 0 );
}
}


It's not an epic improvement, but once you have removed all the duplicate code, i'm sure it will feel better and maybe even run faster.

PS: This text editor (or at least its final representation) is a disgrace.

tbh my first question there wouldn't be about the code it would be the name; "RenderTarget" and "FullScreen" acting on a Window... it makes... no sense!
(and has me more than a little concerned about the rest of the naming scheme and indeed what those classes are doing...)

I also wouldn't use a 'bool' there I would change the function name to SetWindowState and supply an enum with values for Windowed and FullScreen to improve the readablity at both callsite and function location.

PS: This text editor (or at least its final representation) is a disgrace.

What text editor?