forum.boolean.name

forum.boolean.name (http://forum.boolean.name/index.php)

- Проекты C++ (http://forum.boolean.name/forumdisplay.php?f=56)

- - Sigel (http://forum.boolean.name/showthread.php?t=4960)

Потестил. FPS в обоих случаях одинаков - 13.

Хар-ки компа:

Sempron3200+ 1.6Ггц
512 МБ ОЗУ
GeForceGo 6100

26 блитц
31 сигел

Intel(R) Core(TM) 2 CPU 6400 @ 2.13 Ghz
2 GB ОЗУ
Nvidia Geforce 7950 GT 512 MB

А вам не кажется, что условия теста не честны :)
По идее тестируется скокрость отрисовки, или я не так понял? Но зная тормознутость перебора блитца, возможно все ФПС-ки и потерялись. А ещё Мега быстрая блитц математика ))
Так что если тестировать, то в одинаковых условиях.

HolyDel
Подключаются всегда хедеры (.h файлы). Так принято, что реализация хранится в cpp файле и к ней имеет доступ только компиллер. Пользователю же реализация не интересна, его интересует лишь интерфейс, который описывается в хедере.

Имхо, сначала стоит ознакомится со структурой одного из доступных опен-сорсных движков (PopCap Framework, HGE - это 2Д, с 3Д движками пока не разбирался). На собственном опыте проверил. Если писать свой движок с нуля, постепенно добавляешь новые фичи, улучшаешь старые... Рано или поздно наступает момент, когда надо переписать структуру движка. И так не один раз. А это время и силы.

Это лишь имхо. Удачи!

насчет подключения, лично я невижу никакой разницы между етими файлами, но могу сделать одельный интерфейс в h - файл, чтобы cpp глаза не мозолил.
насчет структуры - собственно я сейчас его пишу не для того, чтобы написать. первый блин всегда комом. просто, потренировать мозги на сообразительность. спасибо.

Render, я с тобой согласен, что условия нечестные. тем более наверняка половина из тестирующих не выключала даже DebugMode. собсно мне пока влом переписывать sigel файл, но если кому не в лом, то пусть он вынесет код обновления етих фигур за цикл, примерно так:

Код:

Graphics3D 1024,768,32,1



cam=CreateCamera()

TurnEntity cam,0,180,0

cnt=10000



cube=CreateCube()

tex=LoadTexture("texture.bmp")



EntityTexture cube,tex



last_tick=MilliSecs()



Type cub

        Field dx#,dy#,dz#,x#,y#,z#,ax#,ay#,az#,r#

        Field ent

End Type



For i=1 To cnt

        c.cub=New cub

        c\ax=Rnd(-2,2)

        c\ay=Rnd(-2,2)

        c\az=Rnd(-2,2)

        c\dx=Rnd(-0.005,0.005)*57

        c\dy=Rnd(-0.005,0.005)*57

        c\dz=Rnd(-0.005,0.005)*57

        c\r=Rnd(20,50)

        c\x=Rnd(-1.57,1.57)*57

        c\y=Rnd(-1.57,1.57)*57

        c\z=Rnd(-1.57,1.57)*57

        c\ent=CopyEntity(cube)        

Next

x#=0

y#=0

z#=0



For c.cub=Each cub

        x=Sin(c\x)*c\r

        y=Cos(c\y)*c\r

        z=-50+Sin(c\z)*c\r

        c\x=c\x+c\dx

        c\y=c\y+c\dy

        c\z=c\z+c\dz

        PositionEntity(c\ent,x,y,z)

        TurnEntity(c\ent,c\ax,c\ay,c\az)        

Next



While Not KeyDown(1)



        frames=frames+1

        If(last_tick<MilliSecs()-1000)

                last_tick=MilliSecs()

                fps=frames

                frames=0

        EndIf

        

        RenderWorld

        Text 10,10,fps

        Flip

Wend

все равно меньше. у меня 16-20. тогда как в сиджеле, даже при постоянных апдейтах - 25-29.
собственно я признаюсь, в блице тормозит FrustumCulling, я не знаю как они его делали, но явно по тормозному. в своей ф-ии (для примера брал из NeHe) я вылизал все математические операторы. поетому она и работает быстро. а тормозит дурацкий вывод.

Так, мне стало интересно. Раз тестить то давай по честному :)
Всю математику с цикла в топку. нужно что бы все кубы были в камере, а то их токо половина, к тому же меньшая. И желательно, что бы они равномерно были распределены в пространстве. Вот так будет получше.

Тест нумер 2. Взять несколько моделек, по 40-50 к поли и поганять как их потащит.
Желаетльно Блитц версию в комплект :)

Цитата:

Тест нумер 2. Взять несколько моделек, по 40-50 к поли и поганять как их потащит.

ето пока рано, как подключу VBO, так можно будет и протестить. Вообще, я планирую ето сделать на выходных.

я думаю такой тест, когда половина объектов в камере, а половина нет - более полно отражает картину реальной игры. такчто такой тест уместен.

насчет моделек - дык у меня пока даже загрузки нет. "движку" то всего четыре-пять дней.

ЗЫ. а если поставить все объекты в хоне видимости, то у мну можно и фруструм проверку отрубить, так еще быстрее будет.
да, и еще, если они (объекты) будут статичны, то ето нафиг портит всю картину, их же можно в блице объеденить в один сюрфейс.

Сори за офтоп. Вот пример:

Код:

// MySuperClass.h

#ifndef MY_SUPER_CLASS_H

#define MY_SUPER_CLASS_H





class MySuperClass {

        // куча переменных



public:

        MySuperClass();

        virtual ~MySuperClass();



        void Init();

        void Update();

        void Reset();

        // и еще куча методов

};





#endif /* MY_SUPER_CLASS_H */

Представь теперь реализацию этого класса на тыщу строк. Легче включить интерфейс. В вижуал студио вообще достаточно просто написать

Код:

class MySuperClass;

если исходник включен в проект.

Кроме того, в хедерах есть стражи включения, которые не позволят включить файл несколько раз, что в противном случае приводит к неприятным ошибкам.

Сори еще раз за оффтоп, продолжить можно в аське или чате)

blitz3D - 8 FPS
Sigel - 14-16 FPS

winXP SP2, 384 Озу, Geforce FX5500 128 мб, 1.6 ГЦ

Тестил с выключенным дебаг модом.

а почкму оффтоп? совсем не оффтоп.
я вот о чем, пусть пользователь подключит етот файл, и забудет о его существовании. у него останется тока список ф-ий, которыми он и будет пользоваться, все "левые", юзаемые внутри движка попрятаны по нэймспэйсам, все сложные и редкоиспользуемые ф-ии начинаются с ex, методы тоже.

а вообще, у меня есть h-файл с описанием интерфейсов, и cpp файл с кодом для етого интерфейса, но cpp файл, подключает h-файл, поетому в проект подключается cpp.

реализация класса, ессено вынесена в отдельный cpp файл, там же и пишутся реализации функций, например
void MySuperClass::Update()
{
doSomething();
}

единственное, что у меня в одном файле может быть несколько классов.

HolyDel
если ты подключиш вместо CPP - H файл ... то по идее ничего не изменится

alcoSHoLiK

http://hge.relishgames.com/
http://developer.popcap.com/
Качай, кури исходники.

jimon, а я о чом?
как с ТВОЕЙ точки зрения грамотно организовать подключение?

HolyDel

ну я обычно юзаю ООП с интерфейсами :)

вот практический пример в 4 файла :-)
для конечного проекта надо только IEngine.h и Main.cpp

IEngine.h

Код:

#ifndef HIENGINEH

#define HIENGINEH



class IEngine

{

virtual void Function1() = 0;

virtual void Function2() = 0;

};



#ifdef WIN_DLL_EXPORTS

        #define export_api __declspec(dllexport)

#else

        #define export_api __declspec(dllimport)

#endif



export_api IEngine * CreateEngine();

#endif

CEngine.h

Код:

#ifndef HCENGINEH

#define HCENGINEH



#include "IEngine.h"



class CEngine:public IEngine

{

CEngine();

~CEngine();



void Function1();

void Function2();

};

#endif

CEngine.cpp

Код:

#include "CEngine.h"



CEngine::CEngine()

{

}



CEngine::~CEngine()

{

}



void CEngine::Function1()

{

}



void CEngine::Function2()

{

}



IEngine * CreateEngine()

{

return new CEngine();

}

Main.cpp

Код:

#include "IEngine.h"



void main()

{

IEngine * engine = CreateEngine();

engine->Function1();

engine->Function2();

delete engine;



return;

}

ета конструкция удобна чем :
1)кидаем IEngine.h,CEngine.h,CEngine.cpp в компилятор
и получаем dllку + lib файл
2) даем юзеру dllку, lib файл и IEngine.h он доволен
и делает прогу blabla.exe
3) если меняются только CEngine.h и CEngine.cpp
то можно просто заново скомпилить дллку
и заменить ею старую дллку, перекомпиляция blabla.exe не нужна

в принципе удобная системка :)
но на вкус и цвет товарищей нет ... :)