|
Note: You must be registered in order to post a reply.
|
| masterbooda |
Posted - Dec 12 2004 : 10:04:20 PM
I am currently working on DaBooda Console(or OldSchool) and the resolution is going to be 320x240...DirectX7(yes I am going through backward evolution here)
Well here is the problem... I need some input here on this..
I was going to use 8bit to have palette support, but I am using a method to actually access memory of the backbuffer.. seeing this I can now emulate palette support which is better. Also I know some people(my bro) who cannot even run 8-bit at this resolution.
I do not want the same problems that DaBooda Turbo has, and this is of course lack of support. I need to know if 16bit(which is a pain when it comes to color conversion... like 555 or 565 issue), 24 bit which is good but some computers switch the green and blue which is a pain. 32 bit which is fantastic, but I am worried about support again.
The question I suppose(after endless rambling) is:
Do you think everyone can support 32bit color at 320x240?
DaBooda Out...
P.S. Any input would be appreciated on this point. For anyone interested, this emulator is using strict byte manipulation(bit shifting and such), there will not be a single Blt statement in the entire thing. If I pull this off, expect a tutorial on this... thats a promise Eric. |
| masterbooda |
Posted - Jan 07 2005 : 11:40:59 PM
To 2dCoder,
Thanks for the comments, its much appreciated. You are right, everything that I am doing can be done in vb on a slower scale. This is what I am going to do, I am going to keep using c for thes routines, and release code for both. I will convert these c routines into Visual Basic just to show the principals of it. This way anyone can learn about these methods. They can be applied to more than just 2d games, alot of them are advance array shifting techniques as well as bit masking, sorting, comparing, and etc. This would make me feel better about this project, because everything I am doing can be done in VB but the speed sacrifice is just to great for this engine to function correctly. I understand completely your view point on this subject.. and I hope that showing these routines in VB would be a acceptable compromise.
To Byrk,
At first I was resorting to Arrays to represent my screen... because I wanted palette rotation without having to use an 8-bit color depth. I basically created an array of pointers, each element represented one pixel on the screen, basically it was one byte that pointed to a palette table where color was stored. But I realized I could add other data to this like a zbuffer. This way I can draw my map onto the screen buffer copying the color pointers as well as the zbuffer data. This way each individual pixel will have its own zbuffer value. After a map is drawn, I can go through my sprite list, draw the ones viewed on screen and they will adhere to the zdata on the screen. With this method I can have one map tile have multiple layers. The speed increase with this method is astounding. Basically the engine does not draw a pixel unless it is seen, so each pass is the same, seeing how only one pixel per element is being drawn. Also since the map is redrawn each time using a lookup table, I can just change the pointer of that table to another, I can use this to animate maps with just the changing of one variable. This method believe it or not is what alot of old consoles used to use, especially the nintendo and super nintendo... they didn't have fast processors, so they used such methods to increase speed. Using arrays as graphical data, is simply more effecient that like say direct draw. This engine is using DD7 for now, but this is just to initialize the display and get some memory pointers to surfaces. All drawing is basically done with memory manipulation. I am sorry I was rambling...
DaBooda out... |
| Brykovian |
Posted - Jan 07 2005 : 3:30:08 PM
Booda ...
My gut reaction is to always say -- "do what you have to in order to reach the end goal".
But I am curious why/what you're using the large array handling for ... is this for color/graphics manipulation?
-Bryk |
| 2dcoder |
Posted - Jan 07 2005 : 08:02:08 AM
Looking back at my message, sorry if it came across kind of mean. :) You're obviously a talented coder. Probably a little mis-directed in your projects though. ;) I still think something in 100% VB would be a more worth while project from a community perspective. |
| masterbooda |
Posted - Jan 07 2005 : 04:24:23 AM
I have run this on a 2.6.....my other computer.......and it runs if I am lucky and the weather is right...21fps..and this is only doing a few array manips...I wan't to make old games, that people can play. True this project will recieve no profit, and I am doing it basically for fun value...and coding in c does this for me also....its a hybrid of languages. I am not impressing anybody here....honestly if I was looking to impress I would have designed a 3d engine by now. I just wan't something that works effeciently and if I have to dip into other languages for this, then that is what I will do... I wan't at least 30fps on a 400mhz machine....if I get more that is great....but less just won't do....the game would be choppy because it would be skipping frames to keep up...
And to be honest, old school games weren't written in vb, they where written in c/c#/asm or some other language. Not basic. Basic is great, its fun, its easy...but it simply has some issues when it comes to arrays...that is all.. and that is all c is going to do...the rest is vb. No one is more dissapointed than me on this issue trust me... and I have tried every form of VB optimization known on the web.. it simply is to slow. Like I said earlier, if anybody has any vb routines that will handle Arrays just as fast, tell me, I am anxious to hear it. Just keep in mind I have to mess with every single value of that array...not just a simple copy method...I need actually bit compares....its the only way to draw dynamically with zordering sprites, quickly... this way I do not have to sort, just draw...
About the old school feel, I am keeping that intact.......no rotation, no antializing, not even scaling, no 3d rout's of anykind...just straight up map, couple of overlays, and sprites........simple as that...basically the equivelent of a 16bit console system....... I thought about that and you are right, that is two much..... Simple is better.....C went to my head in this area.... I loved the Super Nintendo system..it is a tight system. But I am going to keep it in between the Nintendo and SuperNintendo range as far as graphics and capability. I feel people will make a better game when they are limited on how it looks. I am waiting for a day when creativity comes back to games...
DaBooda out...
P.s. Sorry again about the C, I simply have no choice on this...
|
| 2dcoder |
Posted - Jan 07 2005 : 02:54:13 AM
This is an interesting project to say the least. I really think you should stick to using 100% VB code for this because:
400mhz machines are dinosaurs to say the least. Even a cheap Walmart HP computer which I just bought the other day as my new "typical newbie test machine" , comes with 256mb of ram, 2.6hz cpu and a really decent on board video 2d/3d from intel, with monitor weighing in at CHEAP $440.00. Do you REALLY think a 400mhz machine is something today's gamer is going to be using? Sure a few office oldies may have configurations like that, but seriously you're assuming TOO low a spec for someone wanting to play or write a game in 2005.
This is a free source code, VB, project right? I would then STICK with 100% vb so we can all learn from the code, try to tighten things up, add to it, etc. Who cares if it runs at 15fps on 400mhz machines. 15fps for a 2D game isn't that bad when you think about it, and that's on the lowest of the low end.
This isn't something we're all going to want to write the next killer 2d shareware game with, there is already commercial 2d/3d engines that do anything we could ever want in a game engine. The "old school" feeling on this project should be the fun from doing all these cool things you're talking about, in strictly 100% VB!
What about trying to add a "mame" type emulator through it? THAT would be a cool side project with this new project as well. Again, WHO cares if it's running slow!!
If you're looking to showcase your speedy C routines, I'd say you're losing focus on what you orginally intended this project to be about. If we want pure speed, let's just stick to Dabooda Turbo, but this project kind of has a retro sound to it, even more so when you think of it being in 100% VB.
If you're not planning to release the source code, or make it strictly VB, you pretty much are indulging in an ego driven excersize in impressing yourself with your code abilities. Fun, interesting sure, but not really anything the community can get behind.
So thumbs down from me until you bring that "old school" feeling back in 100% VB with old school games in mind. |
| masterbooda |
Posted - Jan 06 2005 : 2:40:20 PM
Dear Vb Programmers,
I have bad news.. But it is only bad if you look at in traiterous terms. I am having to resort to C for the Array manipulation routines in DBConsole. This is a bad thing for me, considering I was really shooting for pure VB. But VB is just too limited in this area. And yes some will argue that with the right optimization you can do anything just as fast. Well that is wrong, I am sorry but it is. Trust me I tried every form of optimization I could figure, hours of research, many helping hands, but it just wasn't fast enough. I didn't even get above 15fps on my 400mhz machine, and this was optimized compiled. This is simply no good. I am still using vb, but I am putting all my math and array routines in C. I have ran a test compile and so far 160 fps, and this is manipulating about 10 multidimensional arrays (256, 224) the screen size(vb puked at this on mine).... I even use it to draw to the screen.... Do I feel like a traitor, on some levels yes I do, but I wan't this to run on any machine not just the higher end ones. This is the only way to do this. I love vb for its ease and being able to program a complicated program with very little management, but sometimes you have to resort to something faster.
With that being said.... This thing is incredible so far, C has opened all sorts of doors.. we are talking scaling, rotation, antialiasing, palette rotation, dynamic maps that change with the setting of on variable, parallax(true perspective parallax) and even psuedo polygon fill routines.....and so much more... If anybody know anything about The Super Nintendo, then you will know what I am talking about with mode 7 effects... not to mention I have this thing where it can run in any resolution, bit depth, with math scaling, not hardware, same with the alpha... What this means.... anybody can run this, it is going to be that compatible...
What I would like is an opinion on this C business, and you can call me every word in the book if it makes you feel better. Maybe tell me if there is a method in vb that will do this, if so I will gladly try it...
Thank you for the support you guys have given me so far
DaBooda out... |
| masterbooda |
Posted - Dec 14 2004 : 07:40:15 AM
I am going to use 16 bit color... I figured out a way to convert the color into two bytes and the reason I was reading it wierd was because in memory the bytes are flipped... so after figuring this out it was pretty easy.. and dx7 has some handy built in features for reading color bit masks(slapping head and saying duh)... and the only thing that changes is sometimes the green is 6 bits and others its only 5 bits, so very easy to convert the difference...
This method is truly great, I have run this thing on a cheap computer with a nil integrated video card and it ran just fine... the only problem I see is it is pretty processor intensive but with a little optimization we should get the fps up there... it doesn't really tax the video at all... I have it running about 45 to 50 fps on my 400mhz celeron with a good card, and about 70 on a 1.2 with crap card, so its pretty even tempered on video. Of course this is compiled, at uncompiled its 7 fps... crazy, but true... of course this engine will be compiled into a dll so this won't be an issue..
Thanks for the comments and I will keep progress posted, maybe I will even post a demo to see if compatibility is going to be an issue at all.. and yes DaBooda Turbo is going to be on the back burner awhile sorry guys... but this is too interesting to put down...
DaBooda out...
P.S. I know I sound excited about this, and I am, and this has most likely been done before in vb. But this method opens up all kinds of possibilitys... imagine palette animation, zooming, rotation, even alpha blending in directx7 with no loss of performance and total compatibility... this is why I am excited.. but I will try to tone it down.. lol. |
| 2dcoder |
Posted - Dec 14 2004 : 04:36:33 AM
"P.S. Any input would be appreciated on this point. For anyone interested, this emulator is using strict byte manipulation(bit shifting and such), there will not be a single Blt statement in the entire thing. If I pull this off, expect a tutorial on this... thats a promise Eric."
Wow, I've seen some BlitzBasic type routines that do stuff like this. Sounds like a fun retro project, good luck! |
| 2dcoder |
Posted - Dec 14 2004 : 04:28:59 AM
Hello, |
| masterbooda |
Posted - Dec 13 2004 : 9:04:32 PM
Here is a problem I am now encountering with 16bit resolution...
My card deciphers the two bytes as gggbbbbbrrrrrggg... this is very strange and I can create a conversion for it..
But I also know that some cards arrange the two bytes like bbbbbgggggrrrrrn... the n being null which again I can convert... but I need a method of finding out which cards use which method and using the proper color conversion..
Again universal support would have been lovely here, but we all know how this goes... but I believe 16bit is the way to go, for it seems to be the most supported, just a pain in the rump to convert colors..
As for the method... I simply just have the user entering values of 0 to 31 for color levels... because 11111 is 31 for red and blue in method 1 and 111111 is 63 for the green value wich is really just 32 x 2... its the splitting of the green to compensate, which is going to be the fun part... and a sorely wish vb would let you do straight bit manipulation like 1000 + 0001 = 1001... this would be simple but I will have to do it with bytes...
Any ideas or tutorials on color conversion in 16bit would be greatly appreciated...
DaBooda out... |
| Crysstaafur |
Posted - Dec 13 2004 : 6:21:34 PM
With the issue of alpha support, 24 and 32 modes are striaightforward, I don't think it will be a problem with 16-bit either if we simply convert the needed alpha value into a decimal composite(0.0->0.1->...0.9->1.0) and use it in the alpha module(rightshifting each composite) we talked about earlier. I suspect this mainly has to do with the way color is actually managed on the cards. Some in some modes flip a g for a b. sans rbg instead of rgb. Would there be a way to rearrange hardware color returns back into a normal set of composites? |
| Eric Coleman |
Posted - Dec 13 2004 : 08:21:22 AM
Also, voodoo cards support 16bit only. Most video cards will be either 16bit or 32bit. The best solution is to detect what the video card can support and use whatever is available. I would simply limit it to 16 or 32 bits since those are the most common. |
| Walrus |
Posted - Dec 13 2004 : 06:42:16 AM
Well, 320x240 32-bit works for me. But here's sth else: my card supports 32-bit, but not 24-bit. Is that wierd? |
|
|
| VBGamer |
© |
 |
|
|
|
