How would you like me to send it? E-mail? AIM? MSN? E-mail would probably be the easiest. PM me if you don't want to advertise your e-mail address.Combuster wrote:I'm interested If you want I can send you my directx engine in exchange if you want to. (its stuffed with funky directx features which you may find interesting, including some model loaders you probably won't have).I have a demo program (too big to attach - it's 9.9MB IIRC - I'll send it if anyone wants it)
Suggestions for 2D (now 3D) game framework
- AndrewAPrice
- Member
- Posts: 2299
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
My OS is Perception.
- AndrewAPrice
- Member
- Posts: 2299
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
Here's a link to my latest assignment using my framework: http://messiahandrw.informe.com/viewtopic.php?p=23#23
It uses octrees (recursively splitting a cube into 8 smaller cubes, and render the top level cube which runs through each child node and detects if it's within the camera) and portals ("windows" into another room that only renders the content of the other room if the portal is within the camera (octrees lack a way of excluding objects behind other objects)) to not render what isn't being shown significantly speeding up the calculations required to render each frame.
I've attached a screenshot of the program running in wireframe mode showing that the meshes behind the wall are not being rendered.
I also demonstrate a tight and loose octree (loose octree nodes over lap their inner neighbour nodes by 50% which means objects placed on the boundary of a node will comfortably fit within a child if it is at least less that half the size of the parent node, in a tight octree objects placed on a node's border is just put into a parent node).
The best thing about my implementation of octrees is that the end program does not need to do anything. You can just add as many objects as you'd like to a scene anywhere and it'll automatically construct the octree in memory. To use portals, unfortunately, you have to manually add objects into different rooms and specify where the portals are.
It uses octrees (recursively splitting a cube into 8 smaller cubes, and render the top level cube which runs through each child node and detects if it's within the camera) and portals ("windows" into another room that only renders the content of the other room if the portal is within the camera (octrees lack a way of excluding objects behind other objects)) to not render what isn't being shown significantly speeding up the calculations required to render each frame.
I've attached a screenshot of the program running in wireframe mode showing that the meshes behind the wall are not being rendered.
I also demonstrate a tight and loose octree (loose octree nodes over lap their inner neighbour nodes by 50% which means objects placed on the boundary of a node will comfortably fit within a child if it is at least less that half the size of the parent node, in a tight octree objects placed on a node's border is just put into a parent node).
The best thing about my implementation of octrees is that the end program does not need to do anything. You can just add as many objects as you'd like to a scene anywhere and it'll automatically construct the octree in memory. To use portals, unfortunately, you have to manually add objects into different rooms and specify where the portals are.
- Attachments
-
- shotofpoctree.JPG (54.79 KiB) Viewed 889 times
My OS is Perception.
- AndrewAPrice
- Member
- Posts: 2299
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
I've basically finished version 1 of the framework - I'll package the source (VC++ 2005 only ) and binaries some time later.
Version 2 is going to be a complete rewrite. I'm combining some of the knowledge I've learnt from OSDeving with game deving. My new framework will be made up of:
- The kernel: The "main" parent of the kernel. The application interacts with the framework through the kernel.
- Servers: These handle things like the scene, managing content/network requests, the GUI, Sound, etc.
- Drivers: These interact my framework with other API's (Direct3D/OpenGL, DirectInput/XInput).
- The application: The end application that uses my framework. It'll be the lease privileged level in the kernel.
When I say the application is the lease privileged level, I mean at a theoretical level. There will be certain parts of the framework it can't access. Of course I can't force the end application to abide by this restriction like in a real microkernel
My framework uses smart pointers, and as such the kernel is responsible for memory management.
And drivers will be swappable. You will be able to replace the DirectSound driver with XACT.
Also, I'm going to try to make the framework cross-platform. I'm not promising anything but I'll sort of have a Windows driver for Windows specific code.
Version 2 is going to be a complete rewrite. I'm combining some of the knowledge I've learnt from OSDeving with game deving. My new framework will be made up of:
- The kernel: The "main" parent of the kernel. The application interacts with the framework through the kernel.
- Servers: These handle things like the scene, managing content/network requests, the GUI, Sound, etc.
- Drivers: These interact my framework with other API's (Direct3D/OpenGL, DirectInput/XInput).
- The application: The end application that uses my framework. It'll be the lease privileged level in the kernel.
When I say the application is the lease privileged level, I mean at a theoretical level. There will be certain parts of the framework it can't access. Of course I can't force the end application to abide by this restriction like in a real microkernel
My framework uses smart pointers, and as such the kernel is responsible for memory management.
And drivers will be swappable. You will be able to replace the DirectSound driver with XACT.
Also, I'm going to try to make the framework cross-platform. I'm not promising anything but I'll sort of have a Windows driver for Windows specific code.
My OS is Perception.
- AndrewAPrice
- Member
- Posts: 2299
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
I have my own smart pointer class and garbage collector, and I'm using that internally everywhere possible (an exception being inside my actual smart pointer class of course).
Now, if I define * to be something else in my headers, then any end programs won't be able to declare their own pointers But that'd just be mean.
Now, if I define * to be something else in my headers, then any end programs won't be able to declare their own pointers But that'd just be mean.
My OS is Perception.
- AndrewAPrice
- Member
- Posts: 2299
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
Official homepage of MGF 1 with screenshots:
http://messiahandrw.netfast.org/portfol ... mework.htm
No downloads yet since I haven't separated all my folders and been bothered to upload them. I'm working on MGF 2 now which is a lot more modular (see previous posts).
http://messiahandrw.netfast.org/portfol ... mework.htm
No downloads yet since I haven't separated all my folders and been bothered to upload them. I'm working on MGF 2 now which is a lot more modular (see previous posts).
My OS is Perception.
- bloodhound23
- Member
- Posts: 115
- Joined: Wed Jan 23, 2008 7:13 pm
- Contact: