|
Note: You must be registered in order to post a reply.
|
| masterbooda |
Posted - Apr 24 2005 : 09:36:10 AM
I have written this real simple program:
http://www.daboodasilver.darkwizard.org/tools/DBDebug.zip
Its about 14kb, and only requires directx8 to run...and of course vb runtimes...
What it does is sort of enumerates your hardware, and spits out a index of what it does and doesn't do. I just need people to run this and if it is all P's please do not reply, I am only looking for the F's(stuff in red). Tell me your hardware and tell me exactly how the F's are arranged. For example: Device (Ref) (SoftVertex) PFPP.
This is all I need from you. I am using the findings to produce the new Dabooda engine. I will not persue it, until I can get the graphic core to run on all machines. I am mainly only needing the ones who have problems with running directx8 applications, or can't run dabooda turbo. If you have a laptop or something other than your pc, run it on that one also.
This is much appreciated, I look forward to the results. hopefully I can pin down exactly what most machines have a problem with and the new engine will run on anything.
DaBooda out....
P.S. On second thought, if it all passed, let me know that also, with your hardware........mainly video. I am going to benchmark this thing... |
| Crysstaafur |
Posted - May 01 2005 : 12:52:46 AM
In regards to embedded systems, I would agree that an all in one library whether static or dynamic would be ideal. (less files to deal with) ;)
I've been teasing the idea about maybe porting a wrapper for DBT that functions on the gba...
slightly off-tangent question:
Does anyone know of a compiler whether BASIC or C that can handle com/oo(or com like interfaces) for Beos? |
| VBBR |
Posted - Apr 30 2005 : 7:19:59 PM
I say "bundle everything into one single DLL (or similar)" thinking embedded (Palm  ). But for PC systems a variety would make more sense, I have to say. |
| Crysstaafur |
Posted - Apr 28 2005 : 04:16:35 AM
2dcoder.. w8 until the day someone gets the idea to use static libs.. or god forbid puts all modules in the same exe. Now that's bloated. If the thread processes are kept clean enough, then dynamic linking (dll for win32 or derivatives such as .dll.a files for linux) would be ideal as it would allow the engine to function soley as a kernal (for lack of a better term.. as there are no overlays involved..) It would be no problem at all to keep everything open source regardly of how modules are linked at compile time. Even the support (dynamic) libraries can be open source as well... There are reasons why many of us do see the need... :) |
| 2dcoder |
Posted - Apr 27 2005 : 8:01:32 PM
I see no need for the discussion of dll's. This is an open source project, so a suite of language specific source kernals would be ideal. And THEN you could just merge a library specific to a targer render. DirectX, OpenGL, etc and not have everything done in one massive dll or library. This way you still talk to one specific api style but merge the selected target library for compile time. Plus this method would allow better optimizations for specific versions. Torque2D which implements both DirectX and OpenGL is SOOO bloated it's rediculous! |
| Crysstaafur |
Posted - Apr 27 2005 : 5:09:22 PM
SDL or OpenGL/OpenAL would be pretty tight (but tricky to translate from DX8) If it isn't by all means any help would appreciated as i've been trying to do this for sometime (when I'm not helping with the win32 version)...
If I am not mistaken there are tools in the MinGW kit that may help with the DLL issue..
(converts DLLs into .dll.a files for use between Linux and windows)
A http://www.freebasic.net port would open some interesting possiblities... :)
But, lets try not to forget that support for VB will always be present.. afterall it's DBT's birthplace. ;) |
| VBBR |
Posted - Apr 27 2005 : 4:57:57 PM
Was this supposed to be sarcasm or what?
I mean it won't necessarily be made of SEVERAL DLLs in a plug-in-like system because DLLs only work for Windows which would ruin the portability. But for a VB app for example, you just get (or compile) a version of the DLL that implements DX7, DX8, DX9, OGL and SDL frontends. And in the code you do something like
DBT.SetRenderer DBT_RENDERER_SDL
Anything wrong with this or does it simply look too ambitious? |
| 2dcoder |
Posted - Apr 27 2005 : 4:16:48 PM
"The plan won't be to do DLLs actually but to separate everything into source files and compile it all into the DLL or executable using the renderers you want........"
YES! No DLL's, etc. I could even see a library of source files for specific languages that could be included into the source as mods, functions, classes, etc. Blitz, VB, C++, Java, etc! |
| VBBR |
Posted - Apr 27 2005 : 12:17:02 PM
The plan won't be to do DLLs actually but to separate everything into source files and compile it all into the DLL or executable using the renderers you want. It's C++ BTW and not C# (C# is not portable). DLLs are also windows-only and that's why this thing must be open-source. Heck, my plan is to port it to Palm OS as well.
BTW a software renderer written in C++ means HIGH SPEED. And I'd just LOVE to write one. Just provide me info about what's needed: blitting, scaling, rotating, flipping, etc 
Also each platform could have some ASM-optimized drawing functions, I know a guy that knows ARM ASM and so could do that for Palm OS and PPC for example. |
| Eric Coleman |
Posted - Apr 27 2005 : 10:42:21 AM
Given the ambition of this project, are you still looking for results on the original test? It seems like the current engine is irrelevant now since it seems like you're going to have to do a complete rewrite of the code to make it cross platform. |
| masterbooda |
Posted - Apr 26 2005 : 11:25:46 PM
ok, this is kind of nuts, but I had an idea hit me. I agree with porting this thing into c# completely. But why not take it a step further, make the renderer completely independent from the engine. Well that is what you are saying, but say you make a renderer that is machine spacific, or better yet compatible. What this means is no matter what machine you run a db game on, it will send the information to the render engine...which is codependent on that machine. Say some will run dx7, some dx8, some opengl....etc... Think about it, no matter the game, all the engine is doing is sending this renderer a list of information, sort of like plugins, this way the rendering dll will be 100% compatible to that persons machine........crazy?? That way what the renderer does with the information is up to that specific renderer......it makes sense, thanks again for this new thread of ideas........Crystafur is porting this thing to Linux, so I will tell him to hold off, until we iron this out. And VBBR, I really would like to see status of this thing, this is exciting....
Believe it or not this is where I was heading with the new db version, now it all becomes clearer. One problem, need ideas, what to leave in the engine core and how to send info to another .dll, and make it compatible with all renderers. I guess you could send the information as is, in a specific format, and the makers of the renderers, can base it around this......just thinking out loud.....lol
DaBooda out.... |
| VBBR |
Posted - Apr 26 2005 : 5:25:28 PM
No, really, just because I WROTE it after reading it, doesn't mean the idea wan't on my head for a few days now. It was such a coincidence to see some DBT activity here.
Really, believe me |
| 2dcoder |
Posted - Apr 26 2005 : 4:58:22 PM
"P.S.: and I had this idea from before reading your post, so that you know.." Butofcourse! ;) Hey, the dates on the messages don't lie! :) LOL!!! |
| VBBR |
Posted - Apr 26 2005 : 4:55:39 PM
@2dcoder: I know, I just wanted to express my idea fully from the start
And the main thing in mine is the "porting to C++" part for portability's sake. Heck, an open-source, COMPLETELY cross-platform, renderer independant 2D engine would simply ROCK!!!
P.S.: and I had this idea from before reading your post, so that you know  |
| masterbooda |
Posted - Apr 26 2005 : 3:21:50 PM
Get out of my head!! VBBR......lol.....You are right on track, that is what I am thinking. That would be lovely, the more I think about what 2dcoder said, and then you posting, you are right, why not leave the render engine open for others, but keep the same functions. Ambitious? nah, just smart, thanks guys... This was the reason behind this thing being open source to begin with, so take it to any location you want, I would love to see updates on this, if you decide to go through with it....Also, we are starting a new forum for ideas, mainly things the turbo engine lacks, as far as functionality, for I am at the point now, where I know that this engine is weak in the graphical side, so I will concentrate completely on the structure and functions. Again thanks guys, my head is exploding with new ideas...
DaBooda out..... |
| 2dcoder |
Posted - Apr 26 2005 : 2:47:59 PM
VBBR, that's EXACTLY what Im talking about!!!!!!!!!!!!!!!!!!!!!! |
|
|
| VBGamer |
© |
 |
|
|
|
