|
yeah that will probably work. I will give it a shot.
EDIT: That worked flawless thanks!
modified 20-May-12 5:20am.
|
|
|
|
|
Hi everybody,
I want to get rid of all the imports from the CLR. So I decided to make some functions on my own for example cos() sin() tan() asin() acos().
I already have cos and sin and tan done:
FLOAT Sin( FLOAT A )
{
_asm FLD A;
_asm FSIN;
}
FLOAT Cos( FLOAT A )
{
_asm FLD A;
_asm FCOS;
}
FLOAT Tan( FLOAT A )
{
_asm FLD A;
_asm FPTAN;
}
As you can see I am using inline floating point assembly. But then I thought I could probably use FACOS or FASIN, but those instructions don't exist.
Anybody know how I could constructe asin() and acos(), without using the CLR ofcourse.
Regards,
SystemFiles
|
|
|
|
|
when sine or cosine are known, so is the other (remember sin^2 + cos^2 = 1 ), hence also the tangent. Therefore use FPATAN.
|
|
|
|
|
takes a while before I understand what you mean hehe math actually isn't my best point of programming.
I will get to this later!
|
|
|
|
|
Sorry still dont exactly understand what your saying.
|
|
|
|
|
when you know cos, you know sin (except for its sign); and vice versa.
when you know cos and sin, you know tan. So use FPATAN.
|
|
|
|
|
Here's some old code that may help:
double Vk05Pi = 1.5707963267948966192313216916398;
#define MTH_ASM_IS0(LABEL_IS0) __asm \
{ \
__asm ftst \
__asm fnstsw ax \
__asm test ah, 40h \
__asm jne LABEL_IS0 \
}
#define MTH_ASM_IS1(LABEL_IS1) __asm \
{ \
__asm fld1 \
__asm fcomp \
__asm fnstsw ax \
__asm test ah, 40h \
__asm jne LABEL_IS1 \
}
double FkASinR( double A )
{
if( A > 1 ) return(0);
#ifndef MTH_ASM_USE
A *= A;
if( FkIs1(A, DBL_MIN) ) return(Vk05Pi);
return( atan( sqrt(A/(1-A)) ) );
#else
__asm {
fld A
fmul A
MTH_ASM_IS1(isone)
fld st(0)
fld1
fsubr
fdiv
fsqrt
fld1
fpatan
jmp end
isone:
fstp A
fld Vk05Pi
end:
fstp A
}
return(A);
#endif
}
double FkACosR( double A )
{
#ifndef MTH_ASM_USE
A *= A;
if( FkIs0(A, DBL_MIN) ) return(Vk05Pi);
return( atan( sqrt((1-A)/A) ) );
#else
__asm {
fld A
fmul A
MTH_ASM_IS0(iszero)
fld st(0)
fld1
fsubr
fdivr
fsqrt
fld1
fpatan
jmp end
iszero:
fstp A
fld Vk05Pi
end:
fstp A
}
return(A);
#endif
}
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
|
Hello people,
I was wondering of any good driver development/tutorial websites, books and source code I could "scan," (including source code of your own) cause I'm completely new to this and heard that driver are extremely powerful (especially in kernel-mode) and can do some neat things (firewalls)
Simple Thanks and Regards,
Brandon T. H.
Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
Brandon T. H. wrote: I'm completely new to this and heard that driver are extremely powerful (especially in kernel-mode) and can do some neat things (firewalls)
I think that's an over simplification, but if you are serious then start here[^] and be prepared for a lot of hard work.
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
thank you, very appreciated
Simple Thanks and Regards,
Brandon T. H.
Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
You may also find that any driver specific questions will have a better chance of being seen by the specialists in this forum[^].
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
OSR[^] - These guys are the experts.
Check out their NT Insider articles.
|
|
|
|
|
as superman says, OSR, they do a free mag every two months, its very very good. Their website, osronline, is a must.
http://dumpanalysis.org/ is usefull for analysing dumps, something you are going to be doing a lot of.
Ndis.com is good for network stuff, like firewalls.
Most importantly you want to buy Walter Oneys book, programming the wdm, it is essential.
==============================
Nothing to say.
|
|
|
|
|
Erudite_Eric wrote: you want to buy Walter Oneys book
Bunch of thanks, downloaded it
Erudite_Eric wrote: OSR, they do a free mag every two months, its very very good.
Already signed up
Erudite_Eric wrote: http://dumpanalysis.org/
I'll learn that aswell.
Erudite_Eric wrote: Ndis.com is good for network stuff, like firewalls.
Thank you, this could be very helpful in the future (including everything).
Do you suggest me working for a security company like Faronics (ever heard of Deep Freeze)?
Simple Thanks and Regards,
Brandon T. H.
Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
Yes, it will give you a lot of experience. I have worked on similar products, and file system drivers, such as those used by Faronics to control applicaiton execution and so on are some of the most complex to write.
==============================
Nothing to say.
|
|
|
|
|
I am currently writing a game in C++ using OpenGL and I wonder which is the best way to deal with errors, once they occur (especially in games).
Note: I am currently using possibility 2, but I'm not really happy with it.
1. Exceptions - At first glance they seem to be the perfect for all kinds of errors, but I found out that exceptions can produce heck of a lot of overhead and extra time cost and IMO they're making the code ugly.
2. Return values - It's said that checking success using return values is deprecated since C++'s built-in exception handling. I can't share that opinion, but retrieving a return value and checking it doesn't seem to be an 'elegant' way of doing this and isn't beautiful as well (due to thousands of if and/or switch statements.
3. Return value + global error indicator - This one's really deprecated, even though I somehow liked the errno thingy in C
So, what do you use/what would you use and what would you recommend for my needs?
Thanks in advance.
PS: Do I have some kind of natural aversion to exceptions or are they really not the greatest invention since sliced bread?
|
|
|
|
|
I think in error handling, performance should not be of concern. So, the "I'm writing a game, everything must be fast!" argument doesn't work here. Errors should always be the exception!
Exceptions really help you to write smaller code. When using return values, you have to check them every time. If you forget to do so, you might miss an error. So they are really prone to bugs!
Exceptions on the other hand can't be simply ignored, and I think that's good.
|
|
|
|
|
TomasRiker2 wrote: Errors should always be the exception!
Well said! Can I quote you on this?
|
|
|
|
|
forkbomber wrote: ...but I found out that exceptions can produce heck of a lot of overhead and extra time cost...
See here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
that sir is an *excellent* link to a great detail of information.
Charlie Gilley
<italic>You're going to tell me what I want to know, or I'm going to beat you to death in your own house.
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Joe's articles usually are.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Use exceptions for errors you can't recover from e.g:
- Wrong OpenGL version, throw an exception
- No memory - runtime throws an exception for you
- Can't find a critical game resource, a fall back texture, shader or something else that really must be there
- Some muppet's deleted a delay loaded DLL
- Steam doesn't initialise and you're using it for copy protection
- You can't open any file to save the game - throw an exception
Use return values for things you can recover from, e.g:
- Network connection flakey - you don't want your game to crash 'cause your cheap hosting server in Borneo is offline due to Orang-utan attack
- Can't find a game resource that you have a fallback for
- Steam can't share a file, back off and try again
- You can't open a save game file, back off and try again with a different name
If you're code looks ugly you're not using exceptions for critical errors and you've got exception handlers all over the place.
Ideally for yummy, perfect code you should only have exception handlers:
- At the top level of your code - around main, WinMain or whatever for your platform
- Around thread entry/exit functions
- Around window procedures/GUI callbacks
So basically:
- Exceptions are for critical errors
- Exception handlers only appear when your code is about to disapear UP the call stack into the OS, otherwise madness and the end of western civilisation will result.
Exceptions being really expensive is a myth. See one of the previous posts for details, or hey, measure it yourself.
|
|
|
|
|
Hey there and thanks to everybody for clearing things up.
I'm going to use exceptions now.
|
|
|
|
|
Without directly referencing your enumeration, these are the things you should consider:
1. You can't avoid exceptions completely as some DLLs may throw them, so you at least need to be able to catch them
2. Exceptions provide a built-in mechanism to pass messages and an error identifier, and you can easily extend exception objects to hold additional data.
3. Exceptions will pass control to the level of the next higher try block in the call stack, without having to forward a return values up through several function calls.
4. You can't 'forget' to check for an exception like you can forget to check an error return: provided you catch all exceptions in your main function, you can at the very least issue a meaningful error message before having to exit the program. In fact, exceptions are the only way to 100% prevent a 'silent death' of your application, and will prevent most cases of 'hanging' (except for those caused by infinite loops, and then only those cases where you didn't think to check on preconditions and throw an exception if not met...)
Note that the last point (being almost always able to catch an error before the app breaks down) may also allow you to recover sufficient status information for saving the game and resuming at that point! I would say that is a pretty strong point from the PoV of the gamer.
|
|
|
|