| sdw |
Posted - Mar 30 2004 : 5:47:38 PM
I'm pretty sure I know the answer to this, but I'm gonna ask anyways :)
Which is faster to use, a UDT or a class? I remember seeing somewhere that a UDT is faster. But is a class better to use in a game as, for example, a sprite? Right now I'm using a sprite class and create a new instance of it and add it to a collection everytime the game needs a new sprite. Would it be better for me to just use UDT array instead, seeing how I only use the Public variables of the class anyways? |
| IAC249 |
Posted - Apr 03 2004 : 9:36:33 PM
There is also an interesting little trick you can do with UDT's when reading from sequential access files. For example, say you have the text file player.dat with the following records:
ValdoranM256
ValkirieF234
You can read the file like this:
Private Type AllCharacter
allRecord As String * 12
End Type
Private Type Character
name As String * 8
gender As String * 1
hitPoints as String * 3
End Type
' - The following code should be dropped into a button click event.
Dim hFile As Integer
Dim udtAllChar As AllCharacter
Dim udtChar As Character
hFile = FreeFile()
Open "player.dat" For Input As #hFile
While Not EOF(hFile)
Line Input #hFile, udtAllChar.allRecord
LSet udtChar = udtAllChar
MsgBox udtChar.name
MsgBox udtChar.gender
MsgBox udtChar.hitPoints
Wend
Close #hFile
This is a pretty sweet way to read in data from formatted files without having to resort to Mid$() function calls.
- iac249 |
| Spodi |
Posted - Apr 02 2004 : 6:57:21 PM
quote:
Sorry if I made you think i'm so dumb
You should be sorry, dumby McDumbs-alot.
:D |
| VBBR |
Posted - Apr 02 2004 : 4:41:49 PM
quote:
UDT = User Defined Type
And it's not "a module" but only a structure that can be used within any code module.
Well I DO know what's a User Defined Type but didn't know it was a UDT... I said "it's a module" by guessing what was written here... Sorry if I made you think i'm so dumb in VB that I don't know what a "User Defined Type" was....
quote:
UDT = User Defined Type.
Ex:
Private Type Booger
Gooey As Boolean
Size As Integer
Color As Long
End Type
Private Sub PickNose()
Dim myBooger as Booger
Booger.Size = int(rnd * 10)
End Sub
" Yeah, I know, I know... " Just wanted to link the WHAT to the HOW DO YOU SPELL IT 
Sorry now I see the idiot thing i said... Will edit it. |
| VBBR |
Posted - Apr 02 2004 : 3:36:44 PM
Ah... |
| Spodi |
Posted - Apr 02 2004 : 1:53:20 PM
UDT = Uranium Death Turret
Use it when you have 100,000 flesh-eating cannables coming after you with knives and forks.
Do not use it when you are standing in front of it or you are, for some reason, licking the inside of the barrels. |
| Krisc |
Posted - Apr 01 2004 : 4:47:02 PM
The answer is quite simple really...
Use a UDT when you don't need the object to hold any methods.
Use a class when you do need it to have methods and also maybe inherit.
I am doing some pretty cool things in C# for my game and my Player class is going to inherit from Ship class as will the Enemy class...first I think I need to go Direct3D...bleh! |
| Lachlan87 |
Posted - Apr 01 2004 : 11:58:19 AM
UDT = User Defined Type.
Ex:
Private Type Booger
Gooey As Boolean
Size As Integer
Color As Long
End Type
Private Sub PickNose()
Dim myBooger as Booger
Booger.Size = int(rnd * 10)
End Sub
Edit: Whups! Bryk's wasn't there when I hit reply. |
| Brykovian |
Posted - Apr 01 2004 : 11:55:47 AM
UDT = User Defined Type
And it's not "a module" but only a structure that can be used within any code module (including inside of class modules).
-Bryk |
| VBBR |
Posted - Apr 01 2004 : 10:05:14 AM
Hum... It may seem a dumb question, but... What does "UDT" mean? I know it's something like a class (from what you say here) but does "UDT" mean something like "Unstable Domestic Thread"?
Apologize for my dumbness: I deducted UDT was equal to module or something like that, but KNEW what a User Defined Type was. Just didn't recall "User Defined Type' when I saw "UDT"... |
| Eric Coleman |
Posted - Apr 01 2004 : 12:17:02 AM
Using a class simply to store data isn't really using the class properly. Classes are more of a way to organize a program's logic.
Consider this as a simple example, assume you need to draw some shapes. There are two ways to do this, and its really up to you to decide which you like better. The following is just pseudo code.
Enum Shape
Circle
Square
Rect
End Enum
Draw(vShape as Shape)
Case Circle
Case Square
Case Rect
End Function
Class Circle
Draw Sub
End Sub
End Class
Class Square
Draw Sub
End Sub
End Class
Class Rect
Draw Sub
End Sub
End Class
I personally prefer method one because if I needed to add a new shape, then any any associated functions that are related to the shape, such as a drawing function, then I can easily look at the code used to draw other shapes. The shapes might not be related, but the drawing code is. For example, the code for drawing of a rectangle and a square would be very similar. The downside to this is that you'll have to edit a bunch of different functions, most likely all scatterd in different files, but the upside is that the function will have the code needed to simply and easily add the shape.
In the second example, I didn't show it, but you would probably use some short of polymorphism or use interface inheritance and create some sort of generic 'shape' object and derive things from there. In this method, if you need to add a new shape to your project, then its pretty easy. However, if you need to add a new method or property to your shape, then you'll run into the problem of having to write code for each and every type of class. In a real world case, your classes will be more complicated than a simple shape, and you'll probably have them organized in different locations of your program, most likely in different files. In the case of method 1, you won't have to hunt anything down, you simply write a function to handle all the cases.
So you see, the benfits for one method are the bane of the other, and vice versa. It all really dpends on your own style.
As for your problem, I think your slowdown is the collection. I think if you used an array of classes it would be faster than a collection of classes. If you use a UDT for data or a Class, the trick with keeping arrays fast is to "over dim" the array. For example, Say you have a function "AddItem(itm)" and itm is either a UDT or a class, doesn't matter. The function AddItem(itm) should be something similar to this, and this isn't the best example, but it shows you the trick.
AddItem(itm)
Static ndx
SizeOfArray = ubound(itmArray)
ndx = ndx + 1
if ndx > SizeOfArray Then Dim newSize
newSize = 0.1 * SizeOfArray if newSize < 1000 then newSize = 1000 newSize = newSize + SizeOfArray
Redim Preserve itmArray(newSize)
else
end if
itmArray(ndx) = itm
|
| sdw |
Posted - Mar 31 2004 : 9:21:48 PM
Yeah, I figured the UDT would be faster. You have any idea how much faster it would be? Right now I can get up to 200 classes loaded into a collection and maintain a framerate of 85 per second. After 220 - 250 instances the framerate begins a steep decline to around 40 - 50 fps. As I get further and further into this project I realize I won't be needing any scripting with the sprites anyways so I should probably just convert them from classes to udt. I only use public variables from the class modules anyways so it would be about the same thing as using a udt anyways. Thx for the reply. |
| Spodi |
Posted - Mar 31 2004 : 7:18:45 PM
UDT = Faster
Class = Slower
I have never used a class module before personally, and I've done quite a bit of stuff game-wise. Class modules can be good though. Like, for example, if you want to raise the user's exp, you can make sure it doesn't go to high easily. I think this is what it'd be:
Dim Exp as long
Public Get Sub Exp(ByVal newExpValue)
If newExpValue <= MaxExpValue Then Exp = Exp + newExpValue
End Sub
But this can also be achieved by raising Experience by calling a sub in the same way if you use a UDT:
Public Sub GiveExp(ByVal newExpValue)
If newExpValue <= MaxExpValue Then User.Exp = User.Exp + newExpValue
End Sub
Class modules, I believe, can make things easier and less messy, but UDT will be faster. |
|
|
