3D Modul - Ideen/Vorschläge
Übersicht
BlitzMax, BlitzMax NG AllgemeinGehe zu Seite 1, 2, 3, 4, 5, 6 Weiter
|
VertexBetreff: 3D Modul - Ideen/Vorschläge |
 Mi, März 16, 2005 18:16Antworten mit Zitat 
|
|---|---|---|
|
Hi!
Nach dem ich das Multiplayer Modul für Windows nun fertig habe, wollte ich eine Stufe weiter gehen, und ein 3D Modul auf Basis von OpenGL schreiben. Es sollte änlich wie Blitz3D zu handhaben sein. Gerade das Entity-System hat sich m. M. nach gut bewährt, so das wir hier auch anknüpfen sollten. Hier mal ein wenig Pseudo: Code: [AUSKLAPPEN] Const ENTITY_CLASS_NONE = $01
Const ENTITY_CLASS_PIVOT = $02 Const ENTITY_CLASS_CAMERA = $03 Const ENTITY_CLASS_LIGHT = $04 Type TVector Field fX:Float Field fY:Float Field fZ:Float Field fW:Float End Type Type TRect Field iX:Int Field iY:Int Field iWidth:Int Field iHeight:Int End Type Type TEntity Global oEntityList:TList Field sName:String Field bClass:Byte Field oPosition:TVector Method Free() Abstract End Type Function NameEntity(oEntity:TEntity, sName:String) oEntity.sName = sName End Function Function EntityName:String(oEntity:TEntity) Return oEntity.sName End Function Function PositionEntity(oEntity:TEntity, fX, fY, fZ:Float) oEntity.oPosition.fX = fX oEntity.oPosition.fY = fY oEntity.oPosition.fZ = fZ End Function Function EntityX:Float(oEntity:TEntity) Return oEntity.oPosition.fX End Function Function EntityY:Float(oEntity:TEntity) Return oEntity.oPosition.fY End Function Function EntityZ:Float(oEntity:TEntity) Return oEntity.oPosition.fZ End Function Function FreeEntity(oEntity:TEntity) oEntity.Free() End Function Type TCamera Extends TEntity Field fZoom:Float Field oViewport:TRect Function CreateCamera:TCamera() Local oCamera:TCamera oCamera = New TCamera oCamera.sName = "Untiteled Camera" oCamera.bClass = ENTITY_CLASS_CAMERA oCamera.oPosition = New TVector oCamera.fZoom = 1.0 oCamera.oViewport = New TRect oCamera.oViewport.iX = 0 oCamera.oViewport.iY = 0 oCamera.oViewport.iWidth = GraphicsWidth() oCamera.oViewport.iHeight = GraphicsHeight() TEntity.oEntityList.AddLast(oCamera) Return oCamera End Function Method Free() TEntity.oEntityList.Remove(Self) End Method End Type Function CreateCamera:TCamera() Return TCamera.CreateCamera() End Function Function CameraZoom(oCamera:TCamera, fZoom:Float) oCamera.fZoom = fZoom End Function Function CameraViewport(oCamera:TCamera, iX, iY, iWidth, iHeight) oCamera.oViewport.iX = iX oCamera.oViewport.iY = iY oCamera.oViewport.iWidth = iWidth oCamera.oViewport.iHeight = iHeight End Function Und ein Test dazu: Code: [AUSKLAPPEN] TEntity.oEntityList = CreateList() ' Gehört ins Init
Local MyCamera MyCamera = CreateCamera() NameEntity(MyCamera, "MyCamera") Print "Name: "+EntityName(MyCamera) PositionEntity(MyCamera, 0.0, 0.0, -10.0) Print "X: "+EntityX(MyCamera) Print "Y: "+EntityY(MyCamera) Print "Z: "+EntityZ(MyCamera) FreeEntity(MyCamera) Wobei ich mir jetzt nciht klar bin, ob wir Funktionen mit Set und Get nehmen sollten. Z. B. Kann man zwar den Zoom einer Kamera per CameraZoom setzen, aber nicht auslesen. Was meint ihr zu SetCameraZoom und GetCameraZoom? Also wer hätte Lust? Gefordert sind Kentnisse in OpenGL(besonders da bräuchte ich noch Beratung wenn es z. B. mit Displaylists oder VBOs geht), Mathe(besonders in Vektor/Matrizen), Kollision, und 3D Formaten(z. B. X, 3DS, B3D). OOP ist vorrausgesetzt, ich kann aber auch Teile als OOP einbinden. Postet einfach mal eure Ideen und Vorschläge. mfg olli Edit: Danke Suco, ist geändert! |
||
| vertex.dreamfall.at | GitHub | ||
- Zuletzt bearbeitet von Vertex am Mi, März 16, 2005 18:31, insgesamt 2-mal bearbeitet
|
Suco-XBetreff: ...... |
Mi, März 16, 2005 18:22 Antworten mit Zitat
|
|---|---|---|
|
Mal anschauen. Aber erst mal noch eine Kleinigkeit.
Code: [AUSKLAPPEN] Field fX, fY, fZ, fW:Float So geht das nicht. nur fW ist in diesem Fall Float. Mfg Suco |
||
| Intel Core 2 Quad Q8300, 4× 2500 MHz, 4096 MB DDR2-Ram, GeForce 9600GT 512 MB | ||
Dreamora |
Mi, März 16, 2005 18:50 Antworten mit Zitat
|
|
|---|---|---|
|
Mit dem nächsten Patch wirds dann hoffentlich
field:float fx, fy, fz, fw sein 
Vorschlag: Ein auswechselbare Scene Hierarchy Struktur, die durch einen einen Abstract vorgegeben ist. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
|
TheShadowModerator |
Mi, März 16, 2005 18:52 Antworten mit Zitat
|
|---|---|---|
|
mein Vorschlag:
so wie ich das jetzt hier sehe wirst du irgendwann mit 3D-Modul in Kollision kommen, was Funktionnamen und Types betrifft... An deiner stelle würde ich szeziell dafür einen anderen Stil verwenden: name der engine: xyz Type xyz_TVector Type xyz_TEntity Function xyz_PositionEntity(...) usw... dadurch sicherst du dir später Kompatibilitäten... Man könnte denke ich sogar parallel diese Engines verwenden oder sowas
-edit- und viele variablen und co in eine zeile zu quetschen find eich nicht so gut. der code von vertex ist deutlich sauberer... |
||
| AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2 | ||
|
|
Vertex |
Mi, März 16, 2005 23:30 Antworten mit Zitat
|
|---|---|---|
|
Habe mir von Suco sagen lassen, das Mark an einem 3D Modul z. Z. arbeitet. Insofern macht das alles keinen Sinn.
mfg olli |
||
| vertex.dreamfall.at | GitHub | ||
Dreamora |
Do, März 17, 2005 0:03 Antworten mit Zitat
|
|
|---|---|---|
|
Da es next Gen werden soll, kannst du von min. 8 - 12 monaten entwicklungszeit ausgehen!
Wäre allerdings sinnvoller von Irrlicht, Crystal Space oder OGRE aus zu starten als bei 0, finde ich zumindest. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
Sebe |
Do, März 17, 2005 0:08 Antworten mit Zitat
|
|
|---|---|---|
|
Das hat Fred von PureBasic bei eben diesem versucht: Integration von OGRE. Bisher mit mäßigem Erfolg wie man sagen muss...
Leider! |
||
|
|
Vertex |
Do, März 17, 2005 0:24 Antworten mit Zitat
|
|---|---|---|
|
Ich hoffe diese Angaben stimmen Dreamora Jetzt sind ja bald Ferien, und da werde ich somit doch daran basteln. Habe gerade das DGL Wiki entdeckt, was mir dabei sehr viel nutzen wird.
Naja OGRE wäre m. M. nach das einzig Sinnvolle. Jedoch ist OGRE oo und das lässt sich ja bekanntlich nicht in BMax importieren. Ein Wrapper müsste her. Bin aber eher dafür, selber etwas zu erschaffen. Gerade hier liegt der Reiz für mich. mfg olli |
||
| vertex.dreamfall.at | GitHub | ||
Dreamora |
Do, März 17, 2005 0:31 Antworten mit Zitat
|
|
|---|---|---|
|
Von einem Wrapper halte ich garnix, da es nur noch auf Windows nutzbar wird dadurch -> komplett unbrauchbar
Ich meine effektiv OGRE nach BM portieren, so dass man es als normales Modul nutzen kann. *darum war Irrlicht in der Liste ... die einzige OpenSource engine neben der NeoEngine, die ich kenne, die man noch in sinnvoller zeit portieren könnte  *
|
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
|
stfighter01 |
Do, März 17, 2005 2:47 Antworten mit Zitat
|
|---|---|---|
|
klärt mich mal auf wenn ich etwas falsch verstehe.
aber wieso kann ogre nicht als modul nach blitzmax werden? der gesamte source ist in cpp geschrieben und somit sollte sich die sache mit dem minigw doch kompilieren lassen. ogre unterstützt meines wissens nach auch opengl. ich bin mit dem aufbau von renderen nicht wirklich vertraut, aber für die grafikausgabe müsste sich doch auch irgendwie eine schnittstelle finden lassen. und auch wenn vertex absichten eine engine komplett alleine aus dem boden zu stampfen edler natur sind, sind die optimierungen die vonnöten sind um "einigermassen" moderne leistungen zu vollbringen doch ziemlich heftig und ich glaube das dir da alleine die luft ausgehen wird.(nix für ungut, ist nicht bös gemeint) mfg stfighter |
||
| Denken hilft! | ||
Dreamora |
Do, März 17, 2005 2:53 Antworten mit Zitat
|
|
|---|---|---|
|
Weil du ganz einfach die Interfaces net importieren kannst nach BM.
Dadurch wirds in BM dann dummerweise auch nicht nutzbar und du müsstest es recoden, was aufgrund der BM Logik nur eingeschränkt geht. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
|
|
Vertex |
Do, März 17, 2005 9:26 Antworten mit Zitat
|
|---|---|---|
|
Naja von OGRE den kompletten Source nach BMax zu portieren ist massig Arbeit. Ich sage mal mehr, als eine eigene zu schreiben, da man sich ersteinmal mit der kompletten Logik dieser Engine beschäftigen muss. (oder gibt es irgendwo Code-Dokus?). Wegen dem Wrapper: Unter Linux dürfte es doch auch Libs geben ?oder
Direktes wrappen im C++ zu C Code übrigens nicht. Das hatten schon frühere Versuche gezeigt. Die Blitz3D-Engine ist zum Teil auch nur Low-Level so das man in diesem Sinn nicht viel optimieren braucht. mfg olli |
||
| vertex.dreamfall.at | GitHub | ||
|
|
stfighter01 |
Do, März 17, 2005 11:25 Antworten mit Zitat
|
|---|---|---|
|
@dreamora
das mit den interfaces sollte auch soweit kein problem darstellen. denn, wenn das max-modul alles so auf entitys aufgebaut werden soll wie jenes in blitz3D, dann wird eben diese ganze verwaltung in cpp gecoded und erst diese funktionen werden die schnittstelle. @vertex mit viel arbeit muss ich dir recht geben. hab mal probiert selbst die ogre engine zu nutzen, aber in 2 tagen forschung hab ich nicht mal richtig an der oberfläche gekratzt und dann ist es mir zu blöd geworden 
gedankenbruchstücke die ich mir zu optimierung gemacht habe: ...alle möglichst wenig nicht sichtbare polygone sollen gerendert werden... -> ...alle polygone link, rechts u. hinter meinem sichtfeld werden geclippt... ...alle polygone die hinter anderen polygonen im sichtfeld liegen werden clippt, vobei sich hier die zeit für die berechnungen ob dies der fall ist möglichst gering gehalten werden sollte (od. sogar teilweise weggelassen), da sonst hier wieder zeit verlorengeht... ...polygone die transparent od. ausgeblendet sind, bzw. deren textur transparent od maskiert ist,können keine anderen verdecken... hört sich alles logisch an, beinhaltet meiner meinung nach aber sehr viel komplexität. trotzdem bin ich der meinung, es ist nicht klug das rad nochmal zu erfinden, aber ich beobachte auf jedenfall deine schritte
mfg stfighter |
||
| Denken hilft! | ||
Dreamora |
Do, März 17, 2005 11:41 Antworten mit Zitat
|
|
|---|---|---|
|
doch ist schon ein Problem:
BM hat den Garbage Collector nicht C++ Es wäre also ziemlich blödsinnig die Verwaltung in C++ zu belassen und 2 Memory Manager am laufen zu haben. Hinzu kommt, dass ich mit sicherheit nicht der einzige bin, der rein garnix davon hält, BM prozedural zu nutzen. Sprich wenn 3D, dann OOP basierend. Für die anderen haben wir Blitz3D, die brauchen BM net. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
|
Jan_Ehemaliger Admin |
Do, März 17, 2005 12:59 Antworten mit Zitat
|
|---|---|---|
|
harte Worte, Tiger.
Ich bin dafür, Module OOP aufzubauen, aber noch einen Prozedurallle(oder wie das heißt) zu ermöglichen. wenn sie das bei Irrlicht gemacht hätten, wäre das Porten ja kein Problem. |
||
| between angels and insects | ||
|
|
stfighter01 |
Do, März 17, 2005 13:10 Antworten mit Zitat
|
|---|---|---|
|
elend, elend, jetzt versteh ich das problem.
das heisst man müsste neben dem ogre entity management eine art oop-entity-manager in blitzmax am laufen halten, und die könnten nur über prozeduren miteinander kommunizieren. --> pervers damit geht natürlich auch einiges an flexibilität verloren. aber dieses problem stellt sich jetzt auch bei allen anderen engines die nach max portiert werden, somit bleibt wirklich nur die möglichkeit eine in max zu coden um vollständige erweiterbarkeit für max benutzer ermöglichen zu können. trotzdem kann man für jedes ogre grundelement ein gleichwertiges max-objekt erzeugen welches mit diesem dann prozedurial kommuniziert. wenn man nicht gerade mehr können will als die engine uns von haus aus bietet, dann ist das sicher auch eine passable lösung. --> natürlich viel programmieraufwand. |
||
| Denken hilft! | ||
|
|
Vertex |
Sa, März 19, 2005 14:45 Antworten mit Zitat
|
|---|---|---|
|
Hi!
Bin auch der Meinung, dass eine 3D Engine von Mark noch auf sich warten lassen wird. Also ich bin gerade dabei mich mit VertexBufferObjekten zu beschäftigen, und mache schon große Vortschritte. Bzw. ich will nur noch das ganze so umstellen, dass ich keinen Extra-Speicher für die VBOs im RAM anlegen muss, sondern den Pointer von der Graka gleich nutzen kann. Multitexturing werde ich danach mir zu Gemüte führen. Ist aber auch nicht so schwer zu machen wie ich sehe. Wen es interessiert: http://opengl.org/documentation/blue_book_1.0/ als komplette Referenz(bis auf Extensionen wie ARB) werden hier alle Befehle gut erklährt. Dazu gibt es eine nicht komplette deutsche Referenz dazu unter: http://wiki.delphigl.com/index.php/Hauptseite http://delphigl.com/ hat besonders gute Tutorials dazu. http://opengl.org/documentation/red_book_1.0/ eben noch eine Art Hintergrundwissen für die Programmierer. Meiner Meinung nach ersetzt das alles diese NeHe Tutorials womit ich mich nie anfreunden konnte. mfg olli |
||
| vertex.dreamfall.at | GitHub | ||
|
|
Vertex |
So, März 20, 2005 4:13 Antworten mit Zitat
|
|---|---|---|
|
Habe mal heute ein wenig angefangen...
Die Engine heißt Sitio das ist Spanisch und bedeutet "Raum". sitio.bb Code: [AUSKLAPPEN] Strict
Include "entity.bmx" Include "camera.bmx" Include "texture.bmx" Include "brush.bmx" entity.bmx Code: [AUSKLAPPEN] Type TEntity
Global oList : TList Global iCount : Int Field iClass : Int Field sName : String Field bRenderable : Byte Field bVisible : Byte Field oParent : TEntity Field oChildList : TList Field iChildCount : Int Field fPosition : Float[3] Field fRotation : Float[3] Field fScale : Float[3] Field iCollisionType : Int Field fCollisionBox : Float[6] Field fCollisionRadius : Float Field fAlpha : Float Field iBlendMode : Int Field iFXMode : Int Field iOrder : Int Field fShininess : Float Method FreeEntity() Abstract Method CopyEntity:TEntity() Abstract Method Render() Abstract Method EntityInView:Byte(oCamera:TCamera) Return oCamera.InView(Self) End Method Method EntityClass:String() ' comming soon End Method Method NameEntity(sName:String) Self.sName = sName End Method Method EntityName:String() Return Self.sName End Method Method HideEntity() Self.bVisible = False End Method Method ShowEntity() Self.bVisible = True End Method Method EntityVisible:Byte(oEntity:TEntity) Return Self.bVisible End Method Method EntityParent(oParent:TEntity, bGlobal:Byte = True) Self.oParent = oParent If bGlobal = False Then MemCopy Self.fPosition, oParent.fPosition, 12 MemCopy Self.fRotation, oParent.fRotation, 12 EndIf End Method Method GetParent:TEntity() Return Self.oParent End Method Method CountChildren:Int() Return Self.iChildCount End Method Method FindChild:TEntity(sName:String) ' comming soon End Method Method GetChild:TEntity(iIndex:Int) Return TEntity(Self.oChildList.ValueAtIndex(iIndex-1)) End Method Method PositionEntity(fX:Float, fY:Float, fZ:Float, bGlobal:Byte = False) ' comming soon End Method Method EntityX:Float(bGlobal:Byte = False) ' comming soon End Method Method EntityY:Float(bGlobal:Byte = False) ' comming soon End Method Method EntityZ:Float(bGlobal:Byte = False) ' comming soon End Method Method MoveEntity(fX:Float, fY:Float, fZ:Float) ' comming soon End Method Method TranslateEntity(fX:Float, fY:Float, fZ:Float, bGlobal:Byte = False) ' comming soon End Method Method EntityDistance:Float(oEntity:TEntity) Return Sqr((oEntity.fPosition[0]-Self.fPosition[0])^2 + .. (oEntity.fPosition[1]-Self.fPosition[1])^2 + .. (oEntity.fPosition[2]-Self.fPosition[2])^2) End Method Method PointEntity(oTarget:TEntity, bRoll:Byte = False) ' comming soon End Method Method RotateEntity(fPitch:Float, fYaw:Float, fRoll:Float, bGlobal:Byte = False) ' comming soon End Method Method TurnEntity(fPitch:Float, fYaw:Float, fRoll:Float, bGlobal:Byte = False) ' comming soon End Method Method EntityPitch:Float() ' comming soon End Method Method EntityYaw:Float() ' comming soon End Method Method EntityRoll:Float() ' comming soon End Method Method ScaleEntity(fX:Float, fY:Float, fZ:Float, bGlobal:Byte = False) ' comming soon End Method Method EntityType(iType:Int) Self.iCollisionType = iType End Method Method GetEntityType:Int() Return Self.iCollisionType End Method Method EntityBox(fX:Float, fY:Float, fZ:Float, fWidth:Float, fHeight:Float, fDepth:Float) Self.fCollisionBox[0] = fX Self.fCollisionBox[1] = fY Self.fCollisionBox[2] = fZ Self.fCollisionBox[3] = fX+fWidth Self.fCollisionBox[4] = fY+fHeight Self.fCollisionBox[5] = fZ+fDepth End Method Method EntityRadius(fRadius:Float) Self.fCollisionRadius = fRadius End Method Method EntityColor(bRed:Byte, bGreen:Byte, bBlue:Byte, bAlpha:Byte = 255) Abstract Method EntityAlpha(fAlpha:Float) Self.fAlpha = fAlpha End Method Method EntityShininess(fShininess:Float) Self.fShininess = fShininess End Method Method EntityBlend(iBlendMode:Int) Self.iBlendMode = iBlendMode End Method Method EntityFX(iFXMode:Int) Self.iFXMode = iFXMode End Method Method EntityOrder(iOrder:Int) Self.iOrder = iOrder End Method Method EntityTexture(oTexture:TTexture) Abstract Method PaintEntity(oBrush:TBrush) Abstract End Type camera.bmx Code: [AUSKLAPPEN] Const CAMERA_PROJ_PERPECTIVE = 1
Const CAMERA_PROJ_ORTHO = 2 Const CAMERA_COLORBUFFER = 1 Const CAMERA_DEPTHBUFFER = 1 Const CAMERA_FOG_ENABLE = 1 Type TCamera Extends TEntity Field iViewport : Int[4] Field bUseScissor : Byte Field iProjMode : Int Field fRange : Float[2] Field fZoom : Float Field fClsColor : Float[3] Field iClsMode : Int Field fFogColor : Float[4] Field fFogRange : Float[2] Field iFogMode : Int Method Render() Local fTemp:Float[4], oEntity:TEntity If Self.bUseScissor Then glEnable GL_SCISSOR_TEST glScissor Self.iViewport[0], Self.iViewport[1], Self.iViewport[2], Self.iViewport[3] Else glDisable GL_SCISSOR_TEST EndIf glViewport Self.iViewport[0], Self.iViewport[1], Self.iViewport[2], Self.iViewport[3] glMatrixMode GL_PROJECTION Select Self.iProjMode Case CAMERA_PROJ_PERPECTIVE gluPerspective 45.0*Self.fZoom, Self.iViewport[2]/Self.iViewport[3], .. Self.fRange[1], Self.fRange[2] Case CAMERA_PROJ_ORTHO glOrtho 0.0, Self.iViewport[2]*Self.fZoom, 0.0, Self.iViewport[3]*Self.fZoom, .. Self.fRange[1], Self.fRange[2] End Select If Self.iClsMode And CAMERA_COLORBUFFER Then glClearColor Self.fClsColor[0], Self.fClsColor[1], Self.fClsColor[2], 0.0 glClear GL_COLOR_BUFFER_BIT EndIf If Self.iClsMode And CAMERA_DEPTHBUFFER Then glClear GL_DEPTH_BUFFER_BIT EndIf If iFogMode = CAMERA_FOG_ENABLE Then glEnable GL_FOG glFogi GL_FOG_MODE, GL_LINEAR glFogfv GL_FOG_COLOR, Self.fFogColor glFogf GL_FOG_START, Self.fFogRange[0] glFogf GL_FOG_END, Self.fFogRange[1] Else glDisable GL_FOG EndIf glMatrixMode GL_MODELVIEW glLoadIdentity glRotatef Self.fRotation[0], 1.0, 0.0, 0.0 glRotatef Self.fRotation[1], 0.0, 1.0, 0.0 glRotatef Self.fRotation[2], 0.0, 0.0, 1.0 glTranslatef -Self.fPosition[0], -Self.fPosition[1], -Self.fPosition[2] Rem For oEntity = EachIn TEntity.oList If oEntity.bVisible And oEntity.bRenderable Then oEntity.Render() EndIf Next End Rem End Method Method CameraClsColor(bRed:Byte, bGreen:Byte, bBlue:Byte) Self.fClsColor[0] = Float(bRed)/255.0 Self.fClsColor[1] = Float(bGreen)/255.0 Self.fClsColor[2] = Float(bBlue)/255.0 End Method Method CameraClsMode(iClsMode) Self.iClsMode = iClsMode End Method Method CameraFogColor(bRed:Byte, bGreen:Byte, bBlue:Byte) Self.fFogColor[0] = Float(bRed)/255.0 Self.fFogColor[1] = Float(bGreen)/255.0 Self.fFogColor[2] = Float(bBlue)/255.0 End Method Method CameraFogRange(fStart:Float, fEnd:Float) Self.fFogRange[0] = fStart Self.fFogRange[1] = fEnd End Method Method CameraProjMode(iProjMode:Int) Self.iProjMode = iProjMode End Method Method CameraRange(fStart:Float, fEnd:Float) Self.fRange[0] = fStart Self.fRange[1] = fEnd End Method Method CameraViewport(iX:Int, iY:Int, iWidth:Int, iHeight:Int) If iX + iY = 0 And iWidth = GraphicsWidth() And iHeight = GraphicsHeight() Then Self.bUseScissor = False Else Self.bUseScissor = True EndIf Self.iViewport[0] = iX Self.iViewport[1] = iY Self.iViewport[2] = iWidth Self.iViewport[3] = iHeight End Method Method CameraZoom(fZoom:Float) Self.fZoom = fZoom End Method Method CameraProject(fX:Float, fY:Float, fZ:Float) ' comming soon End Method Method InView:Byte(oEntity:TEntity) ' comming soon End Method Function CreateCamera:TCamera() ' comming soon End Function End Type texture.bmx Code: [AUSKLAPPEN] Type TTexture Extends TEntity
End Type brush.bmx Code: [AUSKLAPPEN] Type TBrush Extends TEntity
End Type Naja es ist zumindest ein Anfang, laufen tut da noch garnix. mfg olli |
||
| vertex.dreamfall.at | GitHub | ||
|
|
stfighter01 |
So, März 20, 2005 9:49 Antworten mit Zitat
|
|---|---|---|
|
von der bedienstruktur her siehts ok aus.
aber weisst du eigentlich schon konkret welche engine du verwendest, bzw. ob du selbst was machst? ein haus bauen ohne fundament geht nicht.
mfg stfighter |
||
| Denken hilft! | ||
|
|
Vertex |
So, März 20, 2005 11:11 Antworten mit Zitat
|
|---|---|---|
|
stfighter01: Ich pers. schwanke noch, ob ich eine komplett eigene Engine baue, die logisch struktuiert wäre, bis jetzt wird aber nur Blitz3D nach BMax portiert. Naja Fundament ist hier nur OpenGL.
Ich habe mir mal noch weiter Gedanken gemacht, und sehe, das ja Alphablending hinzu kommt. Somit muss ich die Entitys ja auch noch sortieren. Da stellt sich ersteinmal die Frage, ob ich auch noch die Triangles sortieren muss. Bei Blitz3D kam es ja oft zu Darstellungsfehlern. So wie ich OpenGL verstanden habe, werden halt die übergebenen Polygone nacheinander im Fragmentbuffer eingezeichnet. Setze ich da Alphablending mit rein, wird zum aktuellen Inhalt des Fragmentbuffers die folgenden Polygone mit Alpha eingezeichnet. Also müsste ich die Entitys oder Polygone der Z Achse entlang sortieren, wobei dann auch noch die Kameraposition eine Rolle spielt. Das ganze halte ich für eine große Performancebremse. mfg olli |
||
| vertex.dreamfall.at | GitHub | ||
Gehe zu Seite 1, 2, 3, 4, 5, 6 Weiter
Übersicht
BlitzMax, BlitzMax NG Allgemein
Powered by phpBB © 2001 - 2006, phpBB Group