Two questions - DeltaTime / Lists
BlitzMax Forums/BlitzMax Beginners Area/Two questions - DeltaTime / Lists
| ||
| Hey again people, I'm slowly learning Blitzmax, and it start to feel a little bit more comfortable. Nevertheless, I'm coming into one problem, and one concept I don't understand quite good. So let's start with the problem. I know and understand the function for a deltatimer. I've used it in unity without much problem as this is a function built-in. In Blitzmax, it has no such function. But I did my homeworks, and read the PDF for the newbies. I found a nice Deltatimer, which I plan to reuse later in other projects. As such, I've built a different BMX file just for the deltatime, and import it into my project. I've imported as such : Import "deltatime.bmx" Stop me wherever I'm doing a mistake here. Deltatime is a float. In my code, I've set a type for the player object, which is as such : Type MyObject Field posX : int = 512 Field speedX : int = 0 ... ... ... As it was to be expected, when I multiply the move value for my object with the deltatime, it meets an error (float * int = float) I changed my type into float, like this I have my position and speed in float. But it's still incorrect, because when I want to compile, I got the following error : Type Int and float are unrelated. For that one, I don't quite understand the problem there. If I'm all with floats, I shouldn't get this error. Just for you to figure out my move, here is the code : myobject.posX = myobject.posX - 10 * Delta.time After my calculations, if I round the deltatime, it's become useless, and furthermore, I could risk a multiply by 0. So, what's the solution here ? Thanks for any help you could provide :-) The second thing I don't quite good understand are the Lists. In the PDF I've read, it's quite obvious. I make list to create vehicles datas, sort them, and such... I believe I could use a list in something like a breakout, with different bricks containing the different datas about the bloc (breakable, solid, bonus, ...). But I also found a tutorial somewhere where they apply lists for bullets, in a shooter. And there, I don't understand the move. Bullets are all the same, why create a list then ? Furthermore, what's never explained in the pdf I've read, is how to remove something from the list (like when the brick is destroyed). Any ideas on that one ? Thanks again for your lights :-) Thanks for reading, and for suggestions you might do. |
| ||
| are you perhaps using a "type" called Int somewhere? proper ints and floats are primitives and bmax should be able to mix them without problems. Without seeing it all it sounds to me like a type is getting confused with the primitive of the same name somehow... One way to think of lists is a flexible array. That is an array that can easily be added to or removed from. So if you have say 50 bullets flying around in your game, you could store those bullets in a list. Each step you would iterate through the list and process the update to each bullet. When a bullet hit something and was therefore dead you would then remove it from the list so it no longer exists... (Somewhat off topic, an array where you recycle empty spaces is more efficient for this particular use, but this is a common/simple example.). Also when someone fires a gun it just adds a new bullet to the end of the list. Unlike arrays however lists can be re-ordered without actually moving the contents, just by re-araning the elements order with the list. Lists exist by having one element that then has a reference to the element that comes after it, and so on. Additionally lists (at least in bmax) can hold more than one TYPE of object. So you could have a list that contains all the active bullets, AND all the active missles even though they are different object types. (Again, off topic, in the real world it would be best to have them both subclasses of one type for easier batch manipulation, such as looping through and drawing or updating etc.) Last edited 2010 |
| ||
In your Delta.time I belive you are returning a value not accessing a field so it should be:myobject.posX = myobject.posX - 10 * Delta.time() that is the reason for the unrelated error. Last edited 2010 |
| ||
| Thank you both of you for the answers. Jesse, you're totally right, I forgot the parenthesis... (that's a remaining of unity coding :p, no parenthesis there :s) Now it works, but jeez... What a surprise... I had to increase my move from 10 to 250 to have the same speed on screen... If I remember right, the deltatime is working this way : instead of having a move of 10 pixels / frame, I now have a move of 250 / second... Yeah, now that I'm writing this, it is quite normal... 10 / frame = 60 frames a second = move of 600 by second so basically to have the very same move, I need to add 600 instead of 10... Sounds right now :-) But I'm still having a weird clipping, from time to time, and only in window mode. I'm going to search a little more on this subject. Thanks anyway, it's working fine now :-) Last edited 2010 |
| ||
| I had to increase my move from 10 to 250 to have the same speed on screen... That might have to do with what Unity returns for delta time, and how it does movement in the background When I used a loose float system like you are talking about where what returns is a float value representing (for example) 0-1.0 is one game tick, so you might get 3.5 returned if there is a background "hickup" what I found problematic about this approach is that complex movement formulas become difficult to integrate predictably Take gravity for example, every tick it is accelerating the object, and every tick that acceleration gets added to the objects velocity. Its not a simple multiplication in this case... how do you calculate how much velocity should be applied if 3 ticks worth has passed... now add spline formula in there and I think you will get what I'm saying my approach was to run the entire update process once for every tick (hense why setting a frequency becomes important) and use the final 0-1 remainder in the render process, adding a percentage of DeltaX and DeltaY to the draw location. |
| ||
| From that point of view, I must agree that it might become difficult... The approach I had was fine for standard movement. But in most complex cases, you are absolutely right, even if I didn't made calculations for the moment... But I'll think of that when I evolve... Thanks for this really interesting point of view :-) |
   |