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.

DarkBASIC Professional Discussion / First Person Shooter Muzzleflash Problems

Author
Message
Travis Gatlin
17
Years of Service
User Offline
Joined: 14th May 2009
Location: Oxford, Alabama
Posted: 28th Mar 2013 04:26
Link
So, I have this first person shooter that I'm working on. It's going decently so far, but I've come to an issue with the muzzleflash. I have it programmed on a timer system that goes like this:


It seems like this would work, right? Wrong. For some reason, whenever I run this code, the muzzle only flashes sometimes. It's irregular. I'm honestly stumped on why it would do this. Maybe it's just my system? Could someone help me out and give me an idea on why it's doing this?

Game zip file:
https://docs.google.com/file/d/0BzUN3a1mrruJYjNqdUhlRlJ6eWs/edit?usp=sharing

http://www.3dartistonline.com/user/Travis%20Gatlin
You can find my latest work here. Please comment on my work and tell me what you think!
Back to top
Profile PM Email Website
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 28th Mar 2013 09:58
Link
I can't run the code from where I am, but it looks like it is actually working; it's just that your not giving the naked eye enough time to spot the muzzle flash. You did not set the sync rate, so at what ever frame rate it is running at, having the muzzle flash visible for one frame is too fast. Consider fading it out with alpha transparency; EG: Set Alpha Mapping On.

If this is to be a long term project, consider investing in learning and using particles so you can create more realistic effects more easily.

You've done good to comment the code, but what's missing is line indentation. It will take longer to program without it because the structure is being obscured from the eye.

Quote: "In computer programming, an indent style is a convention governing the indentation of blocks of code to convey the program's structure."
. Wiki.

Your muzzle code is 99% valid however.

Back to top
Profile PM Email Website
Travis Gatlin
17
Years of Service
User Offline
Joined: 14th May 2009
Location: Oxford, Alabama
Posted: 28th Mar 2013 16:22
Link
I did attempt to sync it at one point. I set the sync rate to about 60. However, without it, my code is running at a good 500+ FPS. I'll have to change up some of the variables and the running speed to sync it. I'll give it a shot, though! And I'll indent it.
Thanks for the reply!

http://www.3dartistonline.com/user/Travis%20Gatlin
You can find my latest work here. Please comment on my work and tell me what you think!
Back to top
Profile PM Email Website
Mobiius
Valued Member
23
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 28th Mar 2013 20:21 Edited at: 28th Mar 2013 20:22
Link
You should use a timer to control flashes..

for example, I'd do something like this...


Alter the 125.0 to change the delay between flashes. (125.0 = 1/8 of a second) This code should flash every quarter of a second.

I live for video games! (And beers, and football, and cars!)
See what I live for here: [url]http:\\www.TeamDefiant.co.uk[/url]
Back to top
Profile PM Email Website
Travis Gatlin
17
Years of Service
User Offline
Joined: 14th May 2009
Location: Oxford, Alabama
Posted: 29th Mar 2013 00:04 Edited at: 29th Mar 2013 00:05
Link
Mobiius, you make a really good point. I didn't think of that, at all. Thanks!

http://www.3dartistonline.com/user/Travis%20Gatlin
You can find my latest work here. Please comment on my work and tell me what you think!
Back to top
Profile PM Email Website
Stab in the Dark software
Valued Member
23
Years of Service
User Offline
Joined: 12th Dec 2002
Playing: Badges, I don't need no stinkin badges
Posted: 29th Mar 2013 02:29 Edited at: 29th Mar 2013 02:33
Link
Your game should not be running as 500+ FPS.
You need to use the command "Set Display Mode" and use the vsync parameter.
Use the command "Sync On" and call "Sync" at the bottom of your Do/Loop.
In the editor project properties window set it to "fulldesktop" when you use set display mode.

Example:




[img][/img]


WindowsXP SP3,Vista,Windows 7 SP1, DBpro v7.7RC7
Stab In The Dark Editor
The coffee is lovely dark and deep,and I have code to write before I sleep.
Back to top
Profile PM Email Website
Travis Gatlin
17
Years of Service
User Offline
Joined: 14th May 2009
Location: Oxford, Alabama
Posted: 29th Mar 2013 05:12
Link
SITDS:
I've already done this, and I'm in the process of converting the values over.

http://www.3dartistonline.com/user/Travis%20Gatlin
You can find my latest work here. Please comment on my work and tell me what you think!
Back to top
Profile PM Email Website
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 29th Mar 2013 13:48
Link
Quote: "Your game should not be running as 500+ FPS.
You need to use the command "Set Display Mode" and use the vsync parameter.
Use the command "Sync On" and call "Sync" at the bottom of your Do/Loop.
In the editor project properties window set it to "fulldesktop" when you use set display mode."


I see where you are coming from to a degree, but I'd like to understand myself how these instructions are a necessity. Why must we use those procedures? What kind of problems are caused by not setting vertical sync active with a fixed sync rate? Why must we use full desktop mode?

Back to top
Profile PM Email Website
Travis Gatlin
17
Years of Service
User Offline
Joined: 14th May 2009
Location: Oxford, Alabama
Posted: 29th Mar 2013 16:20
Link
Quote: "What kind of problems are caused by not setting vertical sync active with a fixed sync rate?"

I dunno about the desktop mode part, but the reason a fixed sync rate is good is because everything will look right, no matter the system that's running it. So if I have a game that's running 500+ FPS and I give it to someone with a computer that's not as good as mine, they'll basically experience the game in slowmo. All of the values need to be consistent with a frame rate, which in my case, is 60.

http://www.3dartistonline.com/user/Travis%20Gatlin
You can find my latest work here. Please comment on my work and tell me what you think!
Back to top
Profile PM Email Website
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 29th Mar 2013 18:14 Edited at: 29th Mar 2013 18:27
Link
before I say anything, I really don't see anything wrong with his recommendation, what I can't see is any significant difference between it and countless measures of handling the pipeline.

I could talk all day about timing and synchronizing.

Quote: "it. So if I have a game that's running 500+ FPS and I give it to someone with a computer that's not as good as mine, they'll basically experience the game in slowmo."


Trust me, setting it to 60 fps fixed, 30 fps, 1000 fps, 2000 fps doesn't have anything significance to game speed when a machine is too slow, it will just run it as fast as it can. I've downloaded a game on this forum that ran at 2 fps; (will not mention what game it was lol); what ever fixed framerate that was set at makes no difference.

What happens when some windows program fires up a nice update while playing the game or some bottle neck causes a 40 fps frame drop
, you loose 40 fps and run at 20fps; if it was set to 100, the fps would drop is less noticeable; if left alone, at 500 fps, the frame drop would be even more less noticeable; you wouldn't even be aware of it; and it does suck when you need that clean shot in a game like yours and the frame skips then your on the floor KO'd.

There is a flip side; it's also arguably wise to sleep the CPU and GPU once and a while; give the windows message pipeline some room to breath and cool off the processors. Sleeping also causes a loss frame rate.

In view of mobiius's timer hint, the timer is often used to time the rate of all game actions and animations. People tend to be taught to use the frame rate for timing instead of using the timers; and we are told to use 60 fps, 60 fps, bla bla bla, and I am no exception.

If computer A runs twice as slow, and computer B runs twices as fast; A needs to frame skip, and B needs to sleep - or tell it to do something useful, do some house keeping prior to the next sync. But even that is vague because the best solution is down to your game design.

Based on my game design which uses physics; I don't touch the Screen FPS() function; I time the loop and decide when the game should sync myself; but in simpler programs it is not bad to make use of the quick fix solutions.

Back to top
Profile PM Email Website
Mobiius
Valued Member
23
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 30th Mar 2013 12:22
Link
Quote: "Your game should not be running as 500+ FPS."

I disagree. Your game should run with the highest FPS it can manage, and the coder should implement some kind of timer based movement to ensure that the player experiences the same movement regardless of the game speed.

I like to think of it like this, if I have a game that runs at 200fps, then I add functionality which halves the framerate, the game is still playable. But if I force a lower framerate and the same addition then halves that the game is much less playable.

I live for video games! (And beers, and football, and cars!)
See what I live for here: [url]http:\\www.TeamDefiant.co.uk[/url]
Back to top
Profile PM Email Website
Travis Gatlin
17
Years of Service
User Offline
Joined: 14th May 2009
Location: Oxford, Alabama
Posted: 30th Mar 2013 15:08
Link
Quote: "halves that the game is much less playable."

Wait, if the processor is not having to render as many frames, ie restricted framerate, then wouldn't that mean that the processor wouldn't be having to use as much power to render the game, therefore leaving more room for framerate droppage? I hope that made sense.

http://www.3dartistonline.com/user/Travis%20Gatlin
You can find my latest work here. Please comment on my work and tell me what you think!
Back to top
Profile PM Email Website
Mobiius
Valued Member
23
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 30th Mar 2013 15:36 Edited at: 30th Mar 2013 15:40
Link
Think of it like this. When you add additional functionality and it causes the game to run slower, that means the CPU cannot keep up with the processing required therefore the framerate drops.
The way that sync works is if you set it to run at a particular framerate, (say for example 60fps), that means the CPU has 1 second / 60 frames to perform the entire game loop. (that is 0.0166666666666667 of a second) If it takes less time to calculate everything and render it, then the sync command will literally sleep and does nothing for the remainder of the time. Whilst it's sleeping it's doing nothing. This is time which could be spent rendering the next frame, so if there is a drop in framerate, the CPU has more freedom to catch up.
If it takes longer than this 0.016 of a second, then you get a noticable drop in framerate as the CPU is not fast enough to keep up.

This is why I suggest everything be timer based, so no matter what the fps is, everything looks and works the same. things which need to be processed more often can be, and the screen can be updated the required number of frames per second. (I think it's called de-coupling the render loop or something.)
there has been discussions on the forum on how best to achieve this, but it's basically only doing a sync once every x of a second to simulate the desired fps, whilst having the game loop run as fast as it can. Best of both worlds, and also is forward and backward compatible.

I live for video games! (And beers, and football, and cars!)
See what I live for here: [url]http:\\www.TeamDefiant.co.uk[/url]
Back to top
Profile PM Email Website
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 30th Mar 2013 16:09 Edited at: 30th Mar 2013 16:10
Link
Quote: "if the processor is not having to render as many frames, ie restricted framerate, then wouldn't that mean that the processor wouldn't be having to use as much power to render the game, therefore leaving more room for framerate droppage?"


To add to Mobiius's comments; when the sync is doing its own 'sleep' routine in between these '60' or so frames, which basically means it is not doing anything useful; it is STILL consuming excessive CPU usage (as shown in the task manager), and causing the game to consume more energy; why? Because the internal 'sleep' routine (what ever that is) is not very CPU friendly; far better to use the Matrix1 Nice Sleep/Wait commands; but even then, there is no time for sleeping between each and every frame, it should doing house keeping and as Mobiius stated, kept ready for dealing with frame drops.

Use timers, sync when you need to.

Back to top
Profile PM Email Website
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 1st Apr 2013 20:25 Edited at: 1st Apr 2013 20:27
Link
Quote: "I disagree. Your game should run with the highest FPS it can manage, and the coder should implement some kind of timer based movement to ensure that the player experiences the same movement regardless of the game speed.

I like to think of it like this, if I have a game that runs at 200fps, then I add functionality which halves the framerate, the game is still playable. But if I force a lower framerate and the same addition then halves that the game is much less playable."


I think we are talking about the excess performance. Capping the game at a maximum of 30 or 60 frames per second.

As an AppGameKit developer you should be able to appreciate concepts like "Low Power Consumption". If his game is operating at 500fps, then he can cap the game at 30fps and each frame will STILL take 2ms to draw but spend 31ms doing nothing, as it waits to draw the next frame. So he can give the CPU and GPU massive rest periods if he uses a CPU friendly sleep function. He will be rendering at 30fps and 94% of the time is spent doing nothing literally.

The result will be his battery lasts hours longer, the computer won't heat up, and the app won't slow down other apps.


Quote: "Whilst it's sleeping it's doing nothing. This is time which could be spent rendering the next frame, so if there is a drop in framerate, the CPU has more freedom to catch up.
If it takes longer than this 0.016 of a second, then you get a noticable drop in framerate as the CPU is not fast enough to keep up."


I agree with this logic, and pre-rendering is common. But this is an outmoded view. It's a mobile computing world now, and that means battery life is more important. Also in this case hes running way over 100fps so pre-rendering doesn't matter. His hitting the cap all the time, and if he isn't address the lag spike directly don't paint over it.


Quote: "To add to Mobiius's comments; when the sync is doing its own 'sleep' routine in between these '60' or so frames, which basically means it is not doing anything useful; it is STILL consuming excessive CPU usage (as shown in the task manager), and causing the game to consume more energy; why? Because the internal 'sleep' routine (what ever that is) is not very CPU friendly; far better to use the Matrix1 Nice Sleep/Wait commands; but even then, there is no time for sleeping between each and every frame, it should doing house keeping and as Mobiius stated, kept ready for dealing with frame drops."


Absolutely Sync Rate is a massive CPU waste. The Matrix1 nice sleep will actually rest the CPU. You can also do this without needing a plugin by using the SYNC SLEEP command.

I disagree about hahah house keeping, he will spend most of his time doing nothing. He stated 500fps. So frames only take 2ms. You want this. Even on a desktop PC. Heat is a problem. I have a SLI gaming PC, I had to install 3 extra fans in addition to each GPU's double heatsink and fan, just so it wouldn't freeze while playing Saint's Row.


I think people approach this problem wrong. You need to be thinking about power and performance efficiency. Always assume the player is using a battery. Build better programs.

Check Out This Example:
http://forum.thegamecreators.com/?m=forum_view&t=202812&b=1

Back to top
Profile PM
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 1st Apr 2013 22:11 Edited at: 1st Apr 2013 22:38
Link
This is where we differ in objective, strategy, purpose and circumstance Mage, and I guess my comments are from a single perspective... Maybe the thread poster's FPS game target audience is too competitive for your recommendation, or perhaps too casual for mine.

In your case, you need more emphasis on power consumption because most of your AGK/DBP game players might play on laptops or want to keep desktop PC programs running and their CPU's AND GPU's cool. They download the game, install it, and play it and expect to run it well on what ever machine. Power is crucial there, especially when playing on battery.

My game is 0% lightweight and 100% extreme. Most of my players will be worried about winning competitions and leagues; more worried about performance than power, they may even run the game on 2 monitors; some 3 monitors, they are responsible for CPU usage via control panel, some of them may even choose to use a Kinect.

The game is to be played on a desk, upright and focused, firm with posture and serious about action; not on a coach, on the bed, on the laptop. I might even put a banner on the webpage "NOT FOR LAPTOPS" lol.

They will be more interested in devoting 90% of their hardware to running the game fast to aid competition than to save the energy bill; anyone that competitive is likely to grasp how to control the CPU usage in my game's option panel and possibly in their GPU control panel. They will be able to choose their own performance settings and reduce the effects. My engine will decide how best to run according to machine spec and state by default with CPU friendly settings.

Now you understand that even in my scenario I am most certainly still sleeping the CPU to a degree; like I said above about giving windows applications room to breath. I agree with your comments 100%; but only when the game is not extremely competitive; really competitive.

It's just the type of game it is, anyone who plays it on a laptop cannot be serious about expecting to get far in it. This is not the case with more casual games. It's not a game you can just download and play away without reading the technical recommendations and going through calibration and configuration. Anyone one who wants to play casual will have their own program of activity in the game, but it is the hardcore players who will be the most demanding.

Perhaps the FPS game the thread poster is a hobby, so either way is good.

House keeping...
I guess I'm the odd one out, I am more focused on efficiency and house-keeping which is the removal of unwanted distant assets from memory, rendering pipeline or from disk, which in my case is streamed assets from the network and hard drive. But I suppose that doesn't make sense if your not programming a networked game constantly downloading and exchanging content... You can just keep it all in memory and not think about it, I have to house-keep to put things far from the eye out of action, be it mesh, sound, particle, entity, AI or camera tracking.

Sync Sleep
I thought that Sync Sleep was just as bad as Sleep? Correct me if I am wrong?

Back to top
Profile PM Email Website
Mobiius
Valued Member
23
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 1st Apr 2013 22:36
Link
I'd have to agree with you Mage if this was the AppGameKit section, but it isn't. This is the DBP section where we don't need to worry about battery life.

I doubt games like COD and battlefield worry about it? They operate at the maximum they can to produce the best possible experience they can. (depending on what setting the users have selected that is.) Let the user worry about making sure a laptop has sufficient power, as PC developers, we should be focusing on producing the best possible game we can, and not worrying about saving battery power.

I live for video games! (And beers, and football, and cars!)
See what I live for here: [url]http:\\www.TeamDefiant.co.uk[/url]
Back to top
Profile PM Email Website
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 2nd Apr 2013 12:08 Edited at: 2nd Apr 2013 13:00
Link
Only two of you... ok then.

What we are talking about is having excess performance. Having spare time between frames, and what to do with it.

You have suggested: we take advantage and increase the workload.

I have suggested: we have hit our peak performance goal, so let the computer cool off and conserve energy.


Quote: "In your case, you need more emphasis on power consumption because most of your AGK/DBP game players might play on laptops or want to keep desktop PC programs running and their CPU's AND GPU's cool. They download the game, install it, and play it and expect to run it well on what ever machine. Power is crucial there, especially when playing on battery."

Quote: "I'd have to agree with you Mage if this was the AppGameKit section, but it isn't. This is the DBP section where we don't need to worry about battery life."


http://www.computersupport.com/blog/tag/desktop-vs-laptop

No. You need to worry about battery life. Also, Desktop PC's overheat. I have 2 video cards in SLI and it would freeze playing graphics intensive games. I had to install a huge 8 inch fan and drill holes in the case for air exchange. I have a Gaming Laptop, and a SLI Gaming Desktop. I had to install another fan to blow intake over the hard drives so they would stop seizing up. PC Gaming has evolved.

Laptops outsell desktop PC's (which I hate to admit). 7 out of every 10 computers being sold are laptops.



Quote: "My game is 0% lightweight and 100% extreme. Most of my players will be worried about winning competitions and leagues; more worried about performance than power, they may even run the game on 2 monitors; some 3 monitors, they are responsible for CPU usage via control panel, some of them may even choose to use a Kinect. "


Quote: "They will be more interested in devoting 90% of their hardware to running the game fast to aid competition than to save the energy bill; anyone that competitive is likely to grasp how to control the CPU usage in my game's option panel and possibly in their GPU control panel. They will be able to choose their own performance settings and reduce the effects. My engine will decide how best to run according to machine spec and state by default with CPU friendly settings. "


Think about competition for a moment. In sports they have regulation equipment. White has the same pieces as black in chess. Teamwork, Strategy, Experience, Speed, Intelligence are factors for competition. In your envisioned competition, the person with the fastest computer has an unfair advantage over all others. This is a terrible perspective on competition. It's a hardware race, when it shouldn't be. You can have 3 monitors and awesome performance and still not turn the game into a hardware race.

Keep in mind we are talking about trying to run a game at 500fps instead of capping it at something like 60fps. You are saying you want to give people an advantage over other players by taking advantage of this sort of thing. This is awful. It is horrifying design principle.


Quote: "I doubt games like COD and battlefield worry about it? They operate at the maximum they can to produce the best possible experience they can. (depending on what setting the users have selected that is.) Let the user worry about making sure a laptop has sufficient power, as PC developers, we should be focusing on producing the best possible game we can, and not worrying about saving battery power."


Those games use VSync to limit frame rate. They almost never sit at 100% CPU, what usually happens is the CPU gets to rest waiting for the GPU, which on a proper gaming PC becomes the bottleneck. Some people turn off VSync and frame rate can rocket past 100fps (probably when looking at the ground). Almost every game has a limiter available to the player.

However, VSync for DBP is awful, because the CPU will sit at 100%. It only gives the GPU a break. It sits in a While Loop instead of giving processor control back to Windows.


Quote: "It's just the type of game it is, anyone who plays it on a laptop cannot be serious about expecting to get far in it. This is not the case with more casual games. It's not a game you can just download and play away without reading the technical recommendations and going through calibration and configuration. Anyone one who wants to play casual will have their own program of activity in the game, but it is the hardcore players who will be the most demanding."


That makes it a niche product. You are alienating probably about 80-90% of PC gaming. I wish you were right. This was the way of things 10 years ago.



Quote: "
House keeping...
I guess I'm the odd one out, I am more focused on efficiency and house-keeping which is the removal of unwanted distant assets from memory, rendering pipeline or from disk, which in my case is streamed assets from the network and hard drive. But I suppose that doesn't make sense if your not programming a networked game constantly downloading and exchanging content... You can just keep it all in memory and not think about it, I have to house-keep to put things far from the eye out of action, be it mesh, sound, particle, entity, AI or camera tracking."


You have actually touched something worthy of debate here. If you are running at above 60fps and you're capping it, then you will have spare time in between each frame. Why not handle networking? If you are streaming content, perhaps it can stream faster. Perhaps you can handle networking better and reduce lag. Why stop there, physics can benefit from extra processing too. AI also.

However, you need to ask yourself. Is it worth keeping the CPU maxed 100%? If it is that vital then why doesn't it perform that good under the 60fps cap? Push yourself to build a better program.


Quote: "Sync Sleep
I thought that Sync Sleep was just as bad as Sleep? Correct me if I am wrong?"

I linked a thread that literally proves you wrong in the comment you were responding to.
http://forum.thegamecreators.com/?m=forum_view&t=202812&b=1


In Conclusion,
Having my gaming rig heat up to the boiling point of water (100c) sucks. Having the 6 fans max out loudly sucks. Sweating because the room heats up while gaming sucks. Having everyone on TeamSpeak hear my computer in the background when I talk sucks. Having the same game run for 40 minutes on a 6 hour battery when I swap to my laptop sucks.

I propose in this case instead of running the game 500fps, limit it to 60 and use the spare time to rest the hardware. This will drop the workload literally 88%, while keeping awesome performance. Then we have our cake and eat it too.

We can build better software.

Back to top
Profile PM
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 2nd Apr 2013 12:46
Link
Wow is that how you interpreted what I was saying?

Back to top
Profile PM Email Website
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 2nd Apr 2013 12:52
Link
Quote: " Wow is that how you interpreted what I was saying?"

Yes.

Back to top
Profile PM
Travis Gatlin
17
Years of Service
User Offline
Joined: 14th May 2009
Location: Oxford, Alabama
Posted: 2nd Apr 2013 20:42 Edited at: 2nd Apr 2013 20:44
Link
Alright guys, sorry to interrupt the argument, but I'm having another problem with my game. I'm using Sparky's collision plugin to program standing, going up stairs and ramps, ect.. But for some reason it's not wanting to work. I'll hit something, and it'll move up, but whenever I hit a certain point, it just simply falls through. Not sure why, here's my code:



Edit:
Just a note here, I've tried higher values on the "inc height#,0.5" line. It still does the same thing.

3D modeler, 2D Vector Artist, DBP intermediate. Feel free to email me for contracts\requests
Back to top
Profile PM Email Website
Ortu
DBPro Master
18
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 2nd Apr 2013 21:50 Edited at: 2nd Apr 2013 21:52
Link
rays wont collide with backfaces, make sure all your normals are facing the way you expect them to.

also, you are adjusting the standing height 'after' the collision check, so this wont really do anything unless you move it up before the cast, and getting the collis distance before the cast as you are will give you the result from the last cast wont it? which doesnt really apply to the new current position

try simplifying: drop the distance check and adjustable height and just check a constant standing height *2



Back to top
Profile PM Email Website
Travis Gatlin
17
Years of Service
User Offline
Joined: 14th May 2009
Location: Oxford, Alabama
Posted: 3rd Apr 2013 00:58
Link
Quote: " drop the distance check and adjustable height and just check a constant standing height *2"

Then how would I make my character go up stairs and ramps? The way I understood your statement was that I have to make the character stay at a standing height of 2 at all times.

3D modeler, 2D Vector Artist, DBP intermediate. Feel free to email me for contracts\requests
Back to top
Profile PM Email Website
thenerd
17
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 3rd Apr 2013 03:26
Link
@Mage, Mobiius, Chris Tate: I'm going to pipe in and say that although your opinions differ, it's helpful seeing the different perspectives because it's helping me to rethink how I should be coding the core of my engine. If only dbpro had proper multithreading support...

Back to top
Profile PM Email
Ortu
DBPro Master
18
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 3rd Apr 2013 05:45 Edited at: 3rd Apr 2013 05:46
Link
Quote: "Then how would I make my character go up stairs and ramps? The way I understood your statement was that I have to make the character stay at a standing height of 2 at all times."


no, i meant use a double standing height in calculating the end point of your ray cast.

lets say character height 6 units, current stair ground height is at 10 units, camera say 1 unit above char so camera y = 17

get characters new x/z position and cast ray from camera y (17) to camera y - char height * 2 (5), new collision hits at say stair ground height 10.5 and gives your new y position, finally position character to new x,y,z

with just a single height value as the raycast end point, you may not hit anything, in particular on a down slope. using same meaures as before lets now cast a ray from camera y (17) to camera y - char height (11) you can see we get no collision hit as the stair ground height of 10.5 is outside the range we are checking (11 - 17)

it could be falling through if no collision is detected because it looks like you reset the new y (height#) to 0 each time (which would be the flat ground ground height) and is only raised if you get a collision distance, which meets certain criteria, and appers to be looking at the previous positions collision check

Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2026-07-06 20:52:50
Your offset time is: 2026-07-06 20:52:50