By drawing the needle yourself I mean something like DrawLine(point1, point2), whereas you make point1 fixed at the centre and point2 calculated by the angle that results from the given RPM (you just calculate point2Y = sin(angle) * radius and point2X = cos(angle) * radius).
However the last time I "programmed" VB was in Excel some 10 years ago, so I can't really give you any details on how to draw such lines, I just think it should be possible.
One thing you'll need for sure, no matter which way you take (image or drawing), will be a function that maps the input RPM to a specific angle. It really doesn't do more than calculate how much degrees 1 RPM is worth and then multiply this with the current RPM value. Like you want a rotation of 270° (three quarter of a circle) with a maximum of 9000 RPM, which would mean 1 RPM = 270 / 9000 = 0.03°, so at for example 5000 RPM the angle would be 5000 * 0.03 = 150°. Of course you also need to offset this value because you don't want your needle to start facing east at 0 RPM (you know, on the circle east is 0° respectively 360°, north is 90°, west is 180° and south is 270°).
I suggest you to take a look at how sin and cos work (hint), because only if you understand what you're doing you're going to be successful in the long run. It takes a bit to wrap your head around but it's really not that hard. Don't forget that you might have to convert the degrees to radians before working with the VB6 sin & cos functions, as I don't know which kind of value they expect.
In the end if you manage to get the image rotation to work AND are able to transparently overlay the image on the gauge background then this is probably the easier path, as you can skip most of the trigonometry calculations.
However the last time I "programmed" VB was in Excel some 10 years ago, so I can't really give you any details on how to draw such lines, I just think it should be possible.
One thing you'll need for sure, no matter which way you take (image or drawing), will be a function that maps the input RPM to a specific angle. It really doesn't do more than calculate how much degrees 1 RPM is worth and then multiply this with the current RPM value. Like you want a rotation of 270° (three quarter of a circle) with a maximum of 9000 RPM, which would mean 1 RPM = 270 / 9000 = 0.03°, so at for example 5000 RPM the angle would be 5000 * 0.03 = 150°. Of course you also need to offset this value because you don't want your needle to start facing east at 0 RPM (you know, on the circle east is 0° respectively 360°, north is 90°, west is 180° and south is 270°).
I suggest you to take a look at how sin and cos work (hint), because only if you understand what you're doing you're going to be successful in the long run. It takes a bit to wrap your head around but it's really not that hard. Don't forget that you might have to convert the degrees to radians before working with the VB6 sin & cos functions, as I don't know which kind of value they expect.
In the end if you manage to get the image rotation to work AND are able to transparently overlay the image on the gauge background then this is probably the easier path, as you can skip most of the trigonometry calculations.
No idea if that works, maybe try giving it a shot?
http://www.devx.com/vb2themax/Tip/19360
Or maybe you don't use images but just draw the needle yourself?
http://www.devx.com/vb2themax/Tip/19360
Or maybe you don't use images but just draw the needle yourself?
Oh that's true, VB doesn't have unsigned Integers, so I guess you'd have to take a Long field for OG_BAR then. I think it should be able to make a bitwise AND with Integer and Long fields, the initial problem was just trying to do the operation on the array. Or use the value -32768 for the OG_BAR constant, which should give the same result.
Yeah sorry, I didn't want to discourage you or anything. Everybody starts as a newbie at some point I guess...
That's because Flags is of type word, which is two bytes. Now originally you had defined Flags as a byte array of length 2, which is correct for reading the data, but you can't do bitwise operations with arrays. Instead you have to define Flags as Integer, which in VB6 is also two bytes and therefore what you want.
The only error you have now is that you actually defined an Integer array instead of just an Integer.
So instead of this
it needs to be this
The only error you have now is that you actually defined an Integer array instead of just an Integer.
So instead of this
Flags(0 To 1) As Integer
it needs to be this
Flags As Integer
Packet.Flags and OG_SHIFTLIGHT must be of the same data type. Both should be Integer, I reckon.
Why do so many people fail on the simplest of problems? *sigh* Oh well...
Ever heard of a² + b² = c² ? You can easily calculate the distance between two points in a X/Y coordinate system by calculating dist = sqrt(Xdist² + Ydist²), where Xdist = Xcirle - Xcar and Ydist = Ycircle - Ycar. With this distance you then only need to check if it's shorter or longer than the circle's radius to determine whether the car is inside the circle or outside.
Just make yourself a Circle class like this...
Then somewhere you define your sumo area and do your checks as required...
I haven't tested it, but you get the idea. You can also incorporate automatic conversion of LFS units to metres to make the defining of circle areas a bit more intuitive.
Ever heard of a² + b² = c² ? You can easily calculate the distance between two points in a X/Y coordinate system by calculating dist = sqrt(Xdist² + Ydist²), where Xdist = Xcirle - Xcar and Ydist = Ycircle - Ycar. With this distance you then only need to check if it's shorter or longer than the circle's radius to determine whether the car is inside the circle or outside.
Just make yourself a Circle class like this...
public class Circle
{
private double x, y, r;
public Circle(double x, double y, double r)
{
this.x = x;
this.y = y;
this.r = r;
}
public bool Contains(double carX, double carY)
{
return Math.Sqrt(Math.Pow(x - carX, 2) + Math.Pow(y - carY, 2)) <= r;
}
}
Then somewhere you define your sumo area and do your checks as required...
Circle sumoArea = new Circle(0, 0, 15 * 65535); //Right in the middle of the map (x=0, y=0) with 15 metres radius
...
if (!sumoArea.Contains(car.X, car.Y))
{ //you lose! }
I haven't tested it, but you get the idea. You can also incorporate automatic conversion of LFS units to metres to make the defining of circle areas a bit more intuitive.
What's even more funny is that these people are uploading the hotlaps knowing full well that they will be caught and never be able to upload hotlaps again. Guess they must be huge attention whores to crave the 5 seconds of fame.
In this (and only this) situation the rear tyres only do little if you don't make them steer (=slide) enough. Congrats, you just described the one situation where we all agree drifting is most definitely faster (if you didn't notice, going around a cone = hairpin).
It doesn't matter if it's relative or absolute. If you say the rear tyres do f*** all then that would mean they do nothing (obviously not correct), if you say they do f*** all compared to the front tyres then that would mean the front tyres do the majority of the work, which isn't correct either.
I think you greatly underestimate the speed of today's standard home CPUs. Maintaining the surface track temperature wouldn't be that big of a deal, processing wise. The current physics calculations aren't limiting the CPU either, otherwise the fast forwarding in single player replays wouldn't be possible (there it's doing the calcs as fast as it can). The graphics are much more of a performance killer than all the physics and environment calculations you can throw at it.
I agree that in the end a dynamic environment is needed to properly simulate racing, however a strictly static environment helps greatly in identifying core issues with the physics that would otherwise be masked. Sure, a fully dynamic simulation would help hide some of the most blatant flaws that came to light during the years of hotlapping and searching for every way to exploit the system, but hiding problems instead of fixing them is not the way to go, IMO.
Besides that, that the tyre simulation is "good enough" might be true for other sims (I doubt), but unfortunately not for LFS. It is very good indeed, but still lacking in core aspects such as tyre heating, temperature effects, pressure effects, longitudinal grip, flatspots, etc.
Another thing I'd put before the environment simulation is a proper damage model. The amount of abuse LFS' cars can take is phenomenal and leads to a lot of the far too risky and gung-ho driving behaviour we see in LFS.
Besides that, that the tyre simulation is "good enough" might be true for other sims (I doubt), but unfortunately not for LFS. It is very good indeed, but still lacking in core aspects such as tyre heating, temperature effects, pressure effects, longitudinal grip, flatspots, etc.
Another thing I'd put before the environment simulation is a proper damage model. The amount of abuse LFS' cars can take is phenomenal and leads to a lot of the far too risky and gung-ho driving behaviour we see in LFS.
http://www.lfs.net/?page=loginretreive
It comes up when you enter wrong login details. How I found out? I just tried.
Guess the whole figure-things-out-yourself stick isn't all that popular in today's internet society.
It comes up when you enter wrong login details. How I found out? I just tried.
Guess the whole figure-things-out-yourself stick isn't all that popular in today's internet society.
In your LFS directory. Are you sure you downloaded the full version and not just the patch?
Of course drifting (oversteering beyond the optimal slip angle) can be faster in certain situations, even on tarmac-only courses. It is faster in all situations where the inherent understeer / resistance to turn of the car would make you slow down otherwise. The prime example of this are hairpins, of which we have none in LFS.
There might be even situations (corner & track geometry) where due to the setup compromises a little bit of intentional oversteer helps get the car around the corner faster than you'd be able to without going beyond the optimal slip angle.
It might also be faster to stay on the throttle when you screw up a corner, keeping the turbo spinning instead of going off the throttle to correct the oversteer, which would give you more grip in the tyres but much less torque to use that grip, resulting in a net loss of speed.
Why you get rally into this discussion is beyond me, since the reason they drift long wide turns is a completely different one (the spinning wheels are needed to dig through the loose surface). On tarmac they generally don't drift unless one of the reasons mentioned above applies.
What you have to keep in mind is that a "drift" (not showdrift) can be faster in a certain frame of reference (usually a single turn). If the whole track is your reference frame (you're faster everywhere with a drift) then that simply means you have a crap setup, not that drifting is some magical way to make you faster.
Now even if the drift advantage is for only one corner, what you always have to think about is the whole race as your reference frame. Unless you're doing a two lap stint, drifting will never be faster over the course of a race - your tyres will be shot way before everyone else's. Depending on how long the race is it might be even faster over the long run to take that one corner slower than possible for the benefit of massively increasing tyre life.
Also don't forget that power oversteer in LFS is too efficient. The grip dropoff on longitudinal slip is not severe enough, making full throttle starts and also power oversteer work better than they should.
There might be even situations (corner & track geometry) where due to the setup compromises a little bit of intentional oversteer helps get the car around the corner faster than you'd be able to without going beyond the optimal slip angle.
It might also be faster to stay on the throttle when you screw up a corner, keeping the turbo spinning instead of going off the throttle to correct the oversteer, which would give you more grip in the tyres but much less torque to use that grip, resulting in a net loss of speed.
Why you get rally into this discussion is beyond me, since the reason they drift long wide turns is a completely different one (the spinning wheels are needed to dig through the loose surface). On tarmac they generally don't drift unless one of the reasons mentioned above applies.
What you have to keep in mind is that a "drift" (not showdrift) can be faster in a certain frame of reference (usually a single turn). If the whole track is your reference frame (you're faster everywhere with a drift) then that simply means you have a crap setup, not that drifting is some magical way to make you faster.
Now even if the drift advantage is for only one corner, what you always have to think about is the whole race as your reference frame. Unless you're doing a two lap stint, drifting will never be faster over the course of a race - your tyres will be shot way before everyone else's. Depending on how long the race is it might be even faster over the long run to take that one corner slower than possible for the benefit of massively increasing tyre life.
Also don't forget that power oversteer in LFS is too efficient. The grip dropoff on longitudinal slip is not severe enough, making full throttle starts and also power oversteer work better than they should.
Or you just use the Live Alert feature of LFSW.
Okay, that already sound much more sensible. From my best guess it could be either of those (in no particular order)
- Faulty graphics card
- Overheating graphics card
- Overheating CPU*
- Faulty memory
- Faulty or too low powered PSU*
* I think these are most likely
I'd first check the case for dust and if all the fans are seated correctly and working, then if everything looks OK install some sort of tool that shows you the CPU, GFX card, etc. temperature (there are plenty out there, some freeware/shareware product ought to do it). The best would be if it has a temperature logging function because in non 3D mode it's likely that it's not overheating at all. So fire up the game and when you feel it's shortly before breakdown Alt-Tab out of it and see what the temperature readings look like. Be advised that temperature readings can rise and fall very quickly when you enter/exit a game, that's why the logging would be advisable. If they are above 70°C for the CPU or above 90°C for the GFX card then you're in trouble and need new/better coolers. Below that should be fine, or at least not causing the sudden shutdowns.
That said, overheating of the GFX card normally results in plenty of artefacts before the system shuts down completely, whereas CPU overheating can cause everything to break down relatively quickly, so IMHO if it's overheating, then it's more likely the CPU than the GFX card.
The next most likely thing is that the PSU is faulty or simply not able to provide enough power to the system. Unfortunately I can't give more specific details on how much power you need or how to resolve this (other than trial and error with a better PSU), as I don't know what PSU you currently have nor what your CPU & GFX card combo actually need.
- Faulty graphics card
- Overheating graphics card
- Overheating CPU*
- Faulty memory
- Faulty or too low powered PSU*
* I think these are most likely
I'd first check the case for dust and if all the fans are seated correctly and working, then if everything looks OK install some sort of tool that shows you the CPU, GFX card, etc. temperature (there are plenty out there, some freeware/shareware product ought to do it). The best would be if it has a temperature logging function because in non 3D mode it's likely that it's not overheating at all. So fire up the game and when you feel it's shortly before breakdown Alt-Tab out of it and see what the temperature readings look like. Be advised that temperature readings can rise and fall very quickly when you enter/exit a game, that's why the logging would be advisable. If they are above 70°C for the CPU or above 90°C for the GFX card then you're in trouble and need new/better coolers. Below that should be fine, or at least not causing the sudden shutdowns.
That said, overheating of the GFX card normally results in plenty of artefacts before the system shuts down completely, whereas CPU overheating can cause everything to break down relatively quickly, so IMHO if it's overheating, then it's more likely the CPU than the GFX card.
The next most likely thing is that the PSU is faulty or simply not able to provide enough power to the system. Unfortunately I can't give more specific details on how much power you need or how to resolve this (other than trial and error with a better PSU), as I don't know what PSU you currently have nor what your CPU & GFX card combo actually need.
I was the first one to get the Jagged Alliance 2 sources running on Visual Studio 2005, and also fixed a few bugs.
Yeah...
Yeah...
Wait, so you actually took the advice someone gave you on the internet? Impossible.
Well, if that's the truth then congrats to you, though I don't understand why I should be proud of you doing what you should've been doing from the beginning, not after countless failed threads and even Victor getting mad at you.
Regarding C++, I doubt you'll find much more help than the existing CInsim library. In C++ you either do it yourself or you find some libs somewhere on the internet that do the stuff for you if you can't do it. You definitely won't find anything that manages the InSim interface (apart from whatever CInsim does, I haven't looked at it), your best bet is looking for libs covering common things like networking, etc.
Well, if that's the truth then congrats to you, though I don't understand why I should be proud of you doing what you should've been doing from the beginning, not after countless failed threads and even Victor getting mad at you.
Regarding C++, I doubt you'll find much more help than the existing CInsim library. In C++ you either do it yourself or you find some libs somewhere on the internet that do the stuff for you if you can't do it. You definitely won't find anything that manages the InSim interface (apart from whatever CInsim does, I haven't looked at it), your best bet is looking for libs covering common things like networking, etc.
One word of advice, C# is ridiculously easy compared to C++. If you can't even code C#, you will fail horribly at C++. No offence, but personally I doubt you'd even manage to get the development environment to run, yet compile.
You sure it's the acceleration and not just simply a few seconds after being placed on the grid? Because I have no idea what the acceleration could possibly do to your system to make it crash. The only thing that happens is that sound is played and force feedback commands are generated, though both also happen before hitting the throttle.
You could try installing the latest drivers for your soundcard respectively the onboard sound if you don't have a soundcard, and if you have a steering wheel also the latest wheel drivers.
Random things you could also try:
- Reinstall DirectX
- Reinstall the graphics card drivers
Most important is that you verify what actually causes the crash, because acceleration causing it is really really weird.
You could try installing the latest drivers for your soundcard respectively the onboard sound if you don't have a soundcard, and if you have a steering wheel also the latest wheel drivers.
Random things you could also try:
- Reinstall DirectX
- Reinstall the graphics card drivers
Most important is that you verify what actually causes the crash, because acceleration causing it is really really weird.
This is for the dedicated host (LFS servers) only, not for normal LFS clients.
I dunno how he did it, but it seems the OP turns out to be right.
FGED GREDG RDFGDR GSFDG