Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / My program has issues

Author
Message
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 11th Jun 2009 04:59
Hello i have been using this for about a week, all i have learned are some basic features of dark GDK and i came up with this little program. (that i put in a zip as an attachment) It seems that i have created fake gravity and a suitable ground, but i cannot get the ground to duplicate and i am stuck to one tiny area... and yet if you go off and then press back, you float through the block upwards. I am no expert at this so that was just a run through of my problems.

Attachments

Login to view attachments
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 11th Jun 2009 22:28
I try to answer at least some of the questions in your source code.



This prevents your program from exiting immediately when the ESC key is pressed. Imagine that the user accidentally presses ESC without saving the game first, and the program closes without warning or question, the user won't be happy. It's OK for a test program, but for a finished game, you probably want to ask the user "do you really want to quit?"

If you don't use the dbEscapeKey function, then you don't need this part:



because the program will end on ESC anyway.

Next question:



Sure, the help tells you how: "You can move your sprite by calling the sprite command with new position coordinates."



But there are lots of number twos there and they don't mean the same thing, so maybe it's more understandable like this:



To move left, use negative PIXELS. The IMAGE_NUMBER is the image from which the sprite was created.

Also, you don't need to reload an image every time you want to use it. Just load it once at the beginning of the program, it stays in memory and can be used any number of times by referring to its image number. You don't need to delete the sprite and recreate it when the player "dies" and respawns. Just reposition the sprite at the beginning position again.



You can use a loop, testing for all the sprite numbers with which it could collide. Or, according to the help, you can give zero instead of the second sprite number and it should return the number of the sprite with which it has collided. I haven't tested that yet (I'm also relatively new to DarkGDK) but I suppose the help can be believed.

Try to clean up the code a little bit and you can always come back with more questions.
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 12th Jun 2009 01:42
Well, i tried making an acceleration system but i just screwed it up majorly... i guess ill have to work on it for a while. Thanks for all the help. Ill have many more problems to post up in the near future.
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 12th Jun 2009 05:50
I fixed a few bugs and now this is an updated version, problem is, the car moves backwards at awkward times, and i don't know how to stop the car from crashing into the ground and floating upwards... And i wish to know how to make the camera follow the car and make the background follow with it.

Attachments

Login to view attachments
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 12th Jun 2009 22:59
This is so much better than the previous version! You learn fast. I will try to help with the remaining problems but it takes time to look through all the code. Do you want the car to be able to jump over the hole in the ground when the Up key is pressed? (Which is commented out at the moment.)

As for scrolling the background, there is a nice post in this thread by Lilith with a possible solution, using tiles:

http://forum.thegamecreators.com/?m=forum_view&t=152243&b=22

Scrolling the full-screen background picture is a bit more difficult, although in the end, that's only a sprite too, but the problem is the size. I'm not an expert on 2D games, but I know a method used in the "old times" when computers had limited memory, I think it can still be used: make two pictures which seamlessly join each other on the sides. As you scroll one picture out to the left, you scroll in the second picture from the right. When the first picture has fully disappeared, then place that on the right side to slide in, and so on. (This technique was even used together with "parallax scrolling" when the speed of the background was slower than the foreground, to create the illusion that the background is further away.)

As a first attempt, it could also be interesting to make a game which scrolls only the ground tiles in front of a stationary background.
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 12th Jun 2009 23:35
Minor thing but I'd like to point out the functionality of C/C++ here. You have code that adds 50 back into the current value of Y.

y=y+50;

In terms of time consumed it means very little if anything but the common way to do this is

y += 50;

It may save a very minor bit of time and the compiler may actually treat both the same.



Why bother to load the same file into separate images. You don't need a separate image for each sprite unless each one is different. And as it is you only appear to be using number image number 3

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 13th Jun 2009 02:14
@Lilith
well if you don't create a new image with a new image id each time doesn't it delete any multiples of the same sprite?
kklouzal
15
Years of Service
User Offline
Joined: 15th May 2009
Location: Arizona
Posted: 13th Jun 2009 07:05
dbLoadImage ( "my_image_.png", 1 ); // Loads the image as image 1.

dbSprite ( 3, 0, 0, 1 ); //create sprite 3 at 0x 0y using image 1.

dbHideSprite ( 1 ); //hide sprite 1 or else it will always show up at 0x 0y every frame.

dbPasteSprite ( 1, 30, 40 ); //paste sprite 1 at 30x 40y for this frame.
dbPasteSprite ( 1, 80, 90 ); //paste sprite 1 at 80x 90y for this frame.

See you can paste the same sprite in different locations at the same time with the same image.

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 13th Jun 2009 07:24
Quote: "well if you don't create a new image with a new image id each time doesn't it delete any multiples of the same sprite? "


To the best of my knowledge you can assign the same image to any number of sprites. The sprite is something like a holder of the display properties of the image. Each sprite can display the image differently if the diffuse values are changed, size is manipulated or position changed. I just went into my pong program and gave the player's sprite and the computer's sprite the same image number and both display just fine.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 13th Jun 2009 13:43 Edited at: 13th Jun 2009 15:00
I have a few suggestions for you again.

Regarding the "car moving backwards" problem. This code:



will not guarantee you that the speed will stop at zero. Imagine if the speed is not 0.1 but 0.09999999 (which can happen any time with floating point numbers), then if you do -0.1 + 0.1, the result is still not zero and the car will never stop. To confirm this theory, I included commands to print out the iv and ivb values in the corner of the screen and sure enough, they showed 0.09997-something or a smaller value, but never exactly zero.

A better way to ensure that a variable does not go below zero is this:



But there is a bigger problem with your speed handling. I was surprised that you use two different variables to track forward and backward speed. It should really be done with only one variable, which is positive when the car is moving forward and negative when it is moving backward. I feel you are overcomplicating your life and the program would be better designed with only one speed value.

A suggestion for the "floating car" problem. As far as I see, what you need to determine is whether the car collides into the ground sprite from above (OK) or from the side (not OK). Try this: somewhere at the beginning of the loop, store the vertical coordinate of the bottom edge of the sprite, before moving it. Then after moving, if it collided, check if that sprite bottom-edge was above the top edge of the ground sprite or not. If yes, OK, align with ground. If not, continue falling or die, because it collided sideways. Does that make sense?
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 13th Jun 2009 13:58 Edited at: 13th Jun 2009 19:26
P.S. there was a comment in your source code:



This is initializing the random number generator with the current value of the timer. The purpose is to make the generator produce different values every time you start the program. After this, use the dbRND command every time you want a random number. (The help explains these two commands well.)
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 13th Jun 2009 19:14
@Mireben
Would you be able to post the code for displaying things on the screen, i didn't go through any tutorials, i just looked at other programs and learned from them. It would be greatly appreciated
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 13th Jun 2009 20:05 Edited at: 13th Jun 2009 22:16
K here is my update:
Sections:

void Gravity()
Beginning Sprites
Controls
decellerate (fixed)
------

But new problems (yay)
i tried the pastesprite thing and now my ground wont show up at all, i definitely need a little help with that, and i put the gravity into a seperate (ummm what do you call it) section... and now it doesnt work either due to it doesnt read the variables from the main section. and thats about it.
attached code

Attachments

Login to view attachments
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 14th Jun 2009 13:47 Edited at: 14th Jun 2009 14:58
Another letter for you.

Point 1.

I have mentioned the help several times, do you know where to find it? Start menu, Programs, The Game Creators, Dark GDK, Documentation, Information. If you can't find it there, the help file is installed here: <directory where you installed Dark GDK, default is Program Files, The Game Creators, Dark GDK> / Documentation / Dark GDK.chm.

I seriously recommend to open that and look through the available commands of the language and their descriptions. Even if you don't catch everything at first sight, but you should be aware what are the elements you can use to build your program with. They will come to mind when you need them. Sorry if you already know this, but I have a feeling you haven't looked at the help files yet.


Point 2.

Code for "displaying things on the screen": easy. Use the dbText function for displaying text. If you need to display integer or float values, convert them to text with dbStr function. To display an integer value named Speed at the top left of the screen, you use:


The only trick is that in the beginning of the program (before the main loop, in the initialization part), you need to include this:
otherwise the text would be behind the sprites, so you won't see it.

In the attached file, I have included these instructions for you. (Other corrections are described below.) Copy-paste the whole text into the Main.cpp.


Point 3.

If you expected your variables to "carry over" from the main loop to inside a function, then you need some more learning about the C++ programming language as well, not only Dark GDK. In fact, the main advantage of functions is that they represent a separate "naming space" from your main program. You can use local variables without worrying about ruining the variables of the main program or of any other function. You can use the same-name variable in several functions and they will be all different variables! If you want to pass a variable to a function, then you can either: (a) use function parameters and pass your values as parameters, or (b) define your variables OUTSIDE the main loop. That way, they will be global variables and they will really "carry over", that is, they will be accessible throughout the whole file. (At least, as long as one of the functions does not define a local variable with the same name.)

I praise your initiative to organize the code into different parts, which is a good thing to do, but the implementation can be improved. Perhaps you could have a look at a few C++ language descriptions, for example http://www.cplusplus.com/doc/tutorial/ or http://msdn.microsoft.com/en-us/beginner/cc305129.aspx or even a good book.

For the time being, I attached for you the corrected code, which can at least be compiled. I moved your global variables outside the main function.


Point 4.

Sprite display: The problem with the dbPasteSprite that you tried to use here is that it does not actually create the sprite, it only displays an already created sprite. Therefore it should be used inside the main loop, because if you don't paste the sprite every frame, then it will not appear at all. It is not enough to paste it once in the beginning.

Anyway, I suggest you to ignore the idea about pasting sprites and go back to your previous method which worked just fine, with the only exception that you don't need to reload the image. In the attached code, I pasted back your previous sprite-making lines, only with the re-loading line commented out. Pasting the sprite is an alternative display method and I suggest don't use two different methods in the same program, unless you have a really good reason to. Not even mentioning: don't change what works.


Point 5.

There were some suggestions in my above posts, which have not yet been taken into account in this code:
- I still uphold the idea to redesign the code using only one speed variable instead of two.
- The correction to ensuring that a variable stops changing at zero.
- The idea about checking if the sprite collided from above or from the side.


Point 6.

Style: It may be personal taste, but I find the code a bit difficult to read when you write one-line instructions into two lines. For example, the satement:



should be:



I use the several-line form only when the if contains several instructions which are grouped by the {} brackets.


A last request: next time, it is enough to pack your code files (currently, it is only Main.cpp as long as you don't create other include files) instead of the whole project. I already have your pictures from the previous downloads, and just to look at the code, it's not necessary to download a 9 MB zip file.

Well, I think that gives you enough to think about for a while.

Attachments

Login to view attachments
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 14th Jun 2009 19:02
Quote: "I use the several-line form only when the if contains several instructions which are grouped by the {} brackets."


I generally do this too with the exception that if the conditional and the affected statement take up too much space on one line I'll drop the statement down to the next line. But it's always indented to indicate it's dependence on the condition. And oftentimes the condition becomes exceedingly longish and I break it up into multiple lines with the conditional operators aligned under each other for ease or reading.

The VS editor and compiler can handle really long lines but when you have to print out your code or have to scroll back and forth to examine it it becomes tedious to review.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 14th Jun 2009 20:42
For starters, Thank you Meriben for telling me about that help file, i mean tanks a lot! Haven't gotten around to anything in part 5 or stuff like that, tried to clean up my code but I'm doing something wrong...


It all happened when i put controls into a different function. i had also put Beginning sprites into another function too. Debugged after to see if it would work and it came up with this:

Debug Statement. Attached code just main.cpp
-------------------------------------------------------------------

1>Main.cpp
1>c:\users\...\main.cpp(164) : error C2601: 'Gravity' : local function definitions are illegal
1>c:\users\...\main.cpp(29): this line contains a '{' which has not yet been matched
1>c:\users\...\main.cpp(193) : error C2601: 'ControlPlayer' : local function definitions are illegal
1>c:\users\...\main.cpp(29): this line contains a '{' which has not yet been matched
1>c:\users\...\main.cpp(220) : error C2601: 'BeginningSprites' : local function definitions are illegal
1>c:\users\...\main.cpp(29): this line contains a '{' which has not yet been matched
1>c:\users\...\main.cpp(230) : fatal error C1075: end of file found before the left brace '{' at 'c:\users\...\main.cpp(29)' was matched
1>Build log was saved at "file://c:\Users\...\Debug\BuildLog.htm"
1>A platformer - 4 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

-------------------------------------------------------------------

before i did this i also had another problem. When i debugged only two pieces of ground appeared, even thought there is supposed to be 40 pieces. why would this happen




P.S. I just tried the file uploader applet and no matter what file i put in it, it says its over 50mb, even though its like 4 kb... anyways i got the file attached

Attachments

Login to view attachments
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 14th Jun 2009 23:18
A really quick help before I go to sleep. Your compiler errors are caused by a missing closing bracket. The system believes that you are trying to define the Gravity function within the main loop, because an "if" statement is not closed:



The sprite issue, in the beginning of the program:



Wasn't that 40 in the previous version? You missed a zero.

Just typing mistakes, nothing more serious.
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 14th Jun 2009 23:50
It's relatively easy to track enclosing characters in VC. Place the text cursor to either side of a brace, bracket, parenz, < or > and press Ctl-]. The cursor will jump to its matching counterpart.

When creating your code it's best to place the ending brace for a block of code immediately after placing the starting brace. Then fill in the code. There are a variety of preferred placements for braces but it's all a matter of personal preference. If I'm coding a function the first brace goes on the line following the function header. I'll often use the remaining space to put a comment on what the function does. The closing brace goes directly under the opening brace. If coding a block of code following a conditional or a loop controller the brace goes on the same line. The enclosed code gets indented and the closing brace goes in the same column as the first character of the condition.

Unfortunately the VC editor tries to be helpful but sometimes messes up your indentation.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 15th Jun 2009 01:06
Man you two are a life saver, i could have been at this for days! Just want to let you know how much i appreciate this
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 15th Jun 2009 03:13
I tried to make text appear on the screen with this to show locy
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 15th Jun 2009 20:42
It should work, but the coordinates are the same, so the second print will write over the first and both will be unreadable. Position them apart.
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 15th Jun 2009 20:43 Edited at: 15th Jun 2009 20:44
But when i use the code it says cannot convert float to char *
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 15th Jun 2009 21:02
Oh I see, I completely missed that part. No, you can't just assign a float or integer variable to a string like that. With the normal C/C++ instructions it's a much more complicated process, but I don't even start to explain because you have from one of my previous posts the solution:

pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 15th Jun 2009 23:45 Edited at: 16th Jun 2009 00:00
I have made more improvements!
I dont have any real problems this time, just wanted to give out an update

edit: well there is actually something wrong with the jumping system, it would let u jump if you are on the ground but it will ifyou are over an open space after hitting the ground

Attachments

Login to view attachments
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 16th Jun 2009 01:45
I did some scrolling background work, good news is! it kinda works, but at a horrible cost, the ground for sum reason starts to "stack up on eachother and decides to follow the screen" and thats a problem... heres a screenshot, ill add another post with the code

Attachments

Login to view attachments
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 16th Jun 2009 01:45
Added code:

Attachments

Login to view attachments
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 17th Jun 2009 08:53
Just because I can't resist a debugging session, here is a corrected code for you, with all major problems solved. I have been thinking whether it is good or not to give the whole code to you, because it is generally not a good idea to give out ready code without letting you suffer with it yourself. Finally I decided to let you see this because the gravity/jump code is not so easy to put together. Consider it education but I'm doing it only once!

I was glad to see that you substituted two speed variables with one, this implementation was almost perfect, I improved just one zero/non-zero check.

You know why your ground sprites crowded up in the top left corner of the screen? First you deleted a section of the ground, but then in the display loop, you redisplayed them again. The for loop in the MoveScreen function did not check if the sprite exists or not, it just called the dbSprite for all of them. This command will create the sprite if it does not exist, so the deleted ones will reappear at the top left corner. This is corrected.

An advice: it is generally not good to mix calculation with display. In the program, first you calculated some values, then displayed the sprite, then calculated again, displayed again. This is hard to follow and it is not guaranteed that everything will be displayed at the proper position. First, calculate the position of everything, then display everything. I followed this principle with the corrections.

I was unable to figure out what you really wanted to do with gravity, and even using two (changing) gravity values. The theory of making a jump with gravity is this: When the jump begins, give a starting upward velocity to the sprite. Then, each frame, deduct a constant gravity value from this vertical velocity. Sooner or later, the vertical velocity becomes negative and the sprite begins to fall. (You add the vertical velocity to the Y coordinate of the sprite.) Then, when the sprite hits the ground, set the vertical velocity to zero and the jump is finished. You also need a flag (variable) to indicate if the sprite is jumping or not, this will prevent starting a jump again when in the air (you tried a different method for this but it didn't really work). Falling down a hole in the ground is much the same as jumping, except that the starting vertical velocity is zero.

I tried to change as little as possible on your code but in case of the gravity, I just couldn't avoid changing the whole thing. So the jump works now when you press the Up key.

Another bug was that both the backdrop images and the ground tiles were sliding closer and closer to each other as the car was moving, so the whole scene was "compressed". This was because you positioned the tiles using the speed only. The correct way is to calculate the horizontal position of the car (by adding the speed to the horizontal position) and then position the background by that value.

I also formatted the code a bit. I corrected the indentation and removed the double comments, because I find it easier to navigate and look over the code like this. Repeating the same comment at the beginning and end of a block makes the code crowded and difficult to read, and it is tiresome to do in the long term (double work). If your indentation is correct, you don't need this to see where a block begins or ends. The unused variables are commented out too, because they only disturb you when debugging.

Many comments are included in the code.

Attachments

Login to view attachments
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 17th Jun 2009 19:52 Edited at: 17th Jun 2009 20:02
One more thing, I should have said this already in the previous post. Since I didn't know the intention behind your gravity code, I wanted to show you something which is simple. But of course you can use another calculation method if you want to fine-tune the movement of the car. This is just a basis to build from. Also, I don't want to force my coding style on you too much, even if it's done with the best intention, so have a look at that file and decide how much of it you accept.
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 17th Jun 2009 20:03 Edited at: 17th Jun 2009 21:03
THANK YOU! i knew my code was getting messier and messier as it went on and that caused lots of problems, but THANK YOU! this helps me out so much, ive already learned alot in the 5 minutes i just took looking at it!

Edit: I think where i started screwin up is when i chenged from having it be able to move between the 100 mark and the 800 mark of the x axis to making the car stationary, but how would i go on making it back into that system, i wuld have to tell the screen to ignore it if it was between those parameters or is all hell gonna break loose if i tamper with it

Edit Edit: I tampered with it and now it does some wierd shaky screen thing every time you hit one of the sides.... works if you only go one way but when you hit one of the sides it transfers like an entire screen to the direction... ugh... ill figure it out somehow.

Edit Edit Edit:hmm actually fixed it in the next five mins guess i should leave larger time intervals between posts. heres the code snippet im using to let the car move between, tell me if you hate my coding practice!




Edit Edit Edit Edit: 4th one yay! I got the system for scrolling working really well now and i even made grass top ontop of dirttop so it covers the wheels and you ant actually see it hit the ground, then i tried to make it very long by changing spn(number of land sections and grass) from 100 to about 1000, and then the lag started.... any tips on how to reduce lag?
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 18th Jun 2009 21:38
1000 sprites is a lot. You can try to hide those sprites which are not visible on the screen, by calling the dbHideSprite for the invisible sprites and dbShowSprite for the visible ones, every frame. This reduces lag a little, but to tell the truth, not much. The program will still be laggy, because it still needs to decide for all 1000 whether they are visible or not, and the hide/show calls also take time.

The ultimate solution would be to re-use the same sprites. The whole level may be composed of 1000 elements, but to display just the part which is on the screen, 50 might be enough. However, this method requires careful planning and it is not easy even for an experienced programmer. You would need to build a "map" of your level in memory, then calculate where you are on that map, and position the sprites according to the section you want to display, ignoring the rest. I still don't know how fast that will be, but certainly better than processing 1000 elements each frame.

I think you need to think for a while about what you want to achieve and how, and make some plans with pencil and paper. Yes I know, I hate planning too, but it's not possible to get very far with a project without it. It would also be good to get acquainted with memory structures in C++ (arrays, vectors, lists, struct and the like), to know how you can store large amounts of data in an orderly way. I never tried to make a 2D game (yet?) but if this was my project, I would spend quite a lot of time thinking about the best way to represent the level map in memory.

By the way, there is a 2D game tutorial serial in the TGC newsletter. Although it is for DB Pro and not GDK, you can still learn about the theory by reading it. Unfortunately I haven't had the time to read it from beginning to end yet (I was more interested in 3D stuff), but I'm planning to. In part 3 of that tutorial, it says:

"When the player goes into a different screen, each object used to represent the level is checked to see if it is in screen, if not it will be re-used the next time that particular block is needed."

Yeah, just what I was talking about. Here is the link to the last part, it contains links to all the other parts:

http://darkbasicpro.thegamecreators.com/data/newsletter/newsletter_issue_76.html

Search for "platform game" and you are going to find it.
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 18th Jun 2009 21:53
P.S. In addition to hiding/showing sprites, you can try to avoid collision detection with those sprites which are not visible. That will certainly reduce the lag considerably, since collision detection takes much time.

You still have to make careful planning, since at present display and collision are in two entirely different places, so you will have to reorganize the code. But it is easier to implement than re-using the sprites.
pancakeguy
15
Years of Service
User Offline
Joined: 9th Jun 2009
Location: Great White North
Posted: 18th Jun 2009 23:10
I have actually decided to leave this one for a while, im putting way to much time into it. (about 4 - 5 hours a day and im 15 yo)

I will post the last build of the project if anyone wants to take a look at it.

Well here i go again on my own, the only road I've ever known.

Attachments

Login to view attachments
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 19th Jun 2009 08:49
The grass is nice.

I just wanted to suggest one more thing which occurred to me after the last post yesterday. I put one condition into the DisplayAndCollide function, to collide only with those sprites which are within the screen area, and the speed became much better:



It can be further improved by colliding only with those sprites which are in the immediate vicinity of the car.

This is only a small change but it drastically improves the performance of the program.

I understand the need to let it rest for a while. Return to it when you feel like continuing.

Login to post a reply

Server time is: 2024-10-01 03:35:59
Your offset time is: 2024-10-01 03:35:59