EDT_NULL?

[JunkerKun]

As I could understand EDT_NULL will not render anything at all, but will it compute anything?
Right now I'm checking if the choosed resolution is supported like this:

Code: Select all

device = createDevice(video::EDT_NULL,core::dimension2du(screenWidth,screenHeight),screenBits,fullScreen,shadows,vsync,&inputreceiver);
    video::IVideoModeList* list = device->getVideoModeList();
    bool passed = false;
    for(int i=0;i<list->getVideoModeCount();i++) {
        if (list->getVideoModeResolution(i).Width==screenWidth && 
            list->getVideoModeResolution(i).Height==screenHeight) {
                passed = true;
                break;
        };
    };
    if (!passed) {
        device->drop();
        device = createDevice(deviceType,core::dimension2du(640,480),screenBits,fullScreen,shadows,vsync,&inputreceiver);
    };

But I'm not sure if it will slow down my game since there are two devices created.

[Mel]

It will slow down your program in the extent that it will use as many resources as needed, it will perform all the calculations (matrix transformations, skinning, animators, octree traverse...) the software needs, and all the resources assigned to it cannot be used with any other device, but for instance, a NULL device is thread safe because it is hardware independent, so if you want to use it, it isn't a bad idea to create the NULL devices on diferent threads.

[zprg]

if you init your app from a xmlfile you can use a IXMLReader and it need a device.
so you use first the NULL_device, read the xml with the config and kill it with nulldevice->drop(); and
the nulldevice is dead and uses nothing.

[JunkerKun]

So, basically, if I create NULL device and then drop it, nothing bad happens?

[Mel]

Following the rules, happens nothing bad even if you call a hardware based driver

In short, YES, nothing bad happens XD

[randomMesh]

So, basically, if I create NULL device and then drop it, nothing bad happens?

Using goto is worse

[JunkerKun]

Okay, thanks, guys!

[Mel]

lol@goto...

goto, continue and break; the three forbidden statements of the good practices of programming. Well, break, is reasonable inside a switch case, but out of that...

[CuteAlien]

Creating and deleting a null device is fine. Or just created one and keep it around all the time.

And continue and break are also fine, there is no need to be afraid of them :-)

[Mel]

They are bad practices, but they are there for a reason too.

[CuteAlien]

I don't even think of them as bad practices. The jump caused by break/continue is restricted and clearly defined, so they are not causing the problems with spaghetti code like the wild jumps caused by goto. Without break/continue you can only do early outs by deep nesting if's - I don't think that's better. But I have to admit I also avoided those two commands for a few years before I started loving them.

[Mel]

They break structured programming practices, but if we had to stick to structured programming practices, a method could only have a SINGLE return sentence XD

[CuteAlien]

Ah right, luckily I've never had to draw a single structogram ever once I had passed that programming introduction course in University :-)