| Sr. Guapo |
Posted - May 27 2004 : 5:30:28 PM
OK, here goes. In the DaBooda 2D Engine, I have been having constant problems trying to get it to run. Finally I discovered the line of code giving me the error. The line of code is simply the line which renders the sprite(Tri Strip) to the backbuffer:
Direct3DDevice.DrawPrimitiveUP D3DPT_TRIANGLESTRIP, 2, TextureStrip(0), Len(TextureStrip(0))
The exact error is an automation error, if that helps. I know this has happenned to me before when I have tried drawing 2D triangles in DX8, though not for a while. I can't remember how I fixed it, or if I even did. If anyone has experienced this before, please impart on us your knowledge...  |
| VBBR |
Posted - Jun 10 2004 : 7:10:19 PM
Yeah EACam. I haven't installed the help files because I have only the VB6 CD. Not the MSDN one.
But I have found the docs at the MSDN website anyway.  |
| EACam |
Posted - Jun 10 2004 : 6:29:54 PM
Yup...this is a record all right. This topic has, currently, over 3 times as many replies as the second closest thread, which was started in April. |
| EACam |
Posted - Jun 10 2004 : 09:55:23 AM
I'm not so sure. I know it IS that way for VB 5. But for VB 6, I have to have the MSDN installed for help files to work, otherwise it gives me an error like "MSDN not found, please reinstall ..." .
P.S. Boy, 12 pages. So, Eric, is this a record? |
| Eric Coleman |
Posted - Jun 10 2004 : 08:38:19 AM
Open a project in VB, press F1. You don't need the MSDN CD for the VB help file. the MSDN CD is for other stuff. |
| VBBR |
Posted - Jun 10 2004 : 07:56:18 AM
Hum... that would be good if I had the MSDN CD... well I guess this also exists in the online MSDN, I will take a look, thanks. |
| Eric Coleman |
Posted - Jun 09 2004 : 9:44:31 PM
quote:
Originally posted by VBBR
Does anyone have a link for a page explaining hungarian notation?
It's in the VB help file.
Look under
Visual Basic Documentation
> Using Visual Basic
> > Programmer's Guide (All Editions)
> > > Visual Basic Coding Conventions
There should be 4 topics in that "book," read them all. |
| Sr. Guapo |
Posted - Jun 09 2004 : 11:31:34 AM
I just sa it in a book the other day (some PHP code book...). There isn't much to explain. Basically, it gives a common nomenclature (sorry, too much chemistry), naming scheme, to variables, functions and classes. It can be adapted to suit your needs as well. Here are some of the more common things:
Variable Names:
-always lowercase except at the beginning of a word (if the var name is more than one word): variableOne
-names should describe the values the variable holds (except for loop variables: i, j, etc.): frameRate
-names should have a prefix describing the type of variable: strName, nNumber, dblNumber
Constants:
-always uppercase, words seperated by underscore: CONSTANT_ONE
-rest same as variables
Functions/Subroutines/Methods:
-just like variables: getValue()
Classes:
-Just like variables except the first letter is capitalized: GraphicsEngine
This is all subject to change based on your own preferences, but it provides a good base to build on. |
| VBBR |
Posted - Jun 09 2004 : 10:29:46 AM
Does anyone have a link for a page explaining hungarian notation? |
| EACam |
Posted - Jun 09 2004 : 09:49:14 AM
Oh...and hungarian notation is definately a +. I didn't know what that was for the first 2 yrs or so of my programming life (aka, no life), and then i started using it. One nice thing i've found is that, since VB DOESN'T use hungarian notation, by using it u can have things like
sName As String
whereas
Name As String
would be invalid since VB already uses Name.
Unfortunately, my programming style is like the wind and i have once again neglected to use hungarian notation. It's probably because I had to use a bunch of code i wrote a LONG time ago and i didn't want to seem inconsistent by using hungarian when a lot of the code didn't...i dunno. I should pick it back up tho.  |
| EACam |
Posted - Jun 09 2004 : 09:37:43 AM
Yeah...and actually, using windowed mode is LESS compatable, i believe. If u do recall, there is a Caps value u need to check that specifies if windowed mode is supported, whereas there is no such enumeration for full screen. To me that seems good enough proof that full screen, when done right, is more compatable.
Unfortunately, tho, I have the same problem. In full screen my alt+tab handling (YES, i DO have it) doesn't even work. It causes DX to crash and i haven't the slightest clue why. I think i'll have to rewrite my initialization code and see if i can get it to work, but i'm not sure. From what i hear, however, it is a good idea to load ur textures after restoring, and to me, i feel that if i cant get restoration to work, it wouldn't be any worse for me to just COMPLETELY destroy and re-initialize my window and then reload all the grafix.
But yes, Windowed mode IS slower (and there's no hope of gamma correction in windowed mode - speaking of gamma correction, i still dont have the Interpolate function  ).
Well, theres my 2c.
P.S. VBBR, i'm glad u like my method  , i got it from how MS Visual C++ does its compilation logging. |
| masterbooda |
Posted - Jun 06 2004 : 11:05:09 PM
I know I am slow but that is besides the point :)
As for windowed being slow, I notice no difference on my machine at all and I am running an archaic piece of junk... actually full screen runs a little slower than windowed for me....
Should I give the user the control over this, or simply let it ride, because there is no way to incorporate this without losing something in the engine... stupid window's and stupid alt tab and window's key... I will concentrate on this tommorrow my mind is tired from writing all these tutorials...
Dabooda out... |
| Eric Coleman |
Posted - Jun 06 2004 : 10:49:45 PM
slow, slow, slow. |
| masterbooda |
Posted - Jun 06 2004 : 10:13:54 PM
I'm almost tempted to remove the fullscreen ability anyways, because you can still achieve full screen by maximizing your window and using always on top functions... And Windowed is hundred more times compatible, and the refresh is more stable as well as being able to have any size window, that is a bonus... So any opinions on that?
DaBooda out... |
| masterbooda |
Posted - Jun 06 2004 : 10:11:18 PM
There in lies the problem, because I thought of using the second loop but it would put everything in the clients program on hold. So I thought of maybe skipping the render routine as long as the device is lost, but the rest of the program would run, and they would have to put in an event to notify them. There is no way to install this into the engine without losing one or the other. I will figure something out, but I am tempted to let the user have control over that, because they know when the program has lost focus... and they can set it up to do what they will, because really the engine only runs when one command is called. This will give the user more control, because putting the render loop on pause just wouldn't do.
DaBooda out... |
| Eric Coleman |
Posted - Jun 06 2004 : 7:34:20 PM
You generally want to stop calling any render functions when the device is lost, so the best way to do that is to go into a secondary loop that waits for the device to return, and then it can reload all textures, vertex buffers, and index buffers. If your class stops the program from functioning in any way because the device is lost, then that's just really bad for the program. In a real game you'll still want to be able to transmit and receive any network data and also keep physics simulations running or somehow pause them to avoid a simulated explosion. |
|
|
