Thread: turbo? clean? basic? Is C still a contender?

To Quzah-

You can code C tightly enough in many cases to control the specific mnemonic output of the compiler. This is not a _new_ technique and should have been within your repetoire. Coding it completely in assembler has only a negligible gain. If you're a purist, then hey, go assembler all the way.


To Sorensen--

I almost think you misunderstand what 'portability' means. You can write code that compiles code differently based on whatever compiler it runs on using compiler directives. You can write code that compiles differently based on what processor it's being compiled for. That's as portable as it gets. What more do you want? That gives you all the tools you need to make your code compatible with almost any platform and compiler. Again- what more do you want?

And as for your 'PC Hardware Reference' book-- get real. it doesn't even begin to touch how the computer actually works. Have you ever written an O/S as complicated as DOS or even Windows? Your book only covers the physical layer, not the logical layer.

Your statement-

> ...game/GUI app that doesn't call an API...

reveals your lack of understanding. You don't even know what goes on in the API-- It's so much simpler than you're making it out to be, and that is part of the problem. You don't understand how it works, so it's _complicated_ to you. And you don't want to believe otherwise. Wake up. The _concepts_ are simple, the coding is not.

and as for your statement

> ...32bit protected mode (at PL4)...

This has _nothing_ to do with compatibility or with the C language for that matter. Protected mode is a function of your O/S. __Patch it out.__ You don't really thing your O/S or DirectX is hampered by this do you-- they aren't. That's an arbitrary limitation for poorly behaved applications.

Again, to all-

As for writing a graphics library, I ask you all to step back and think about an algorithm to display a single pixel. That's it. All graphic libraries stem from this and almost all routines are nearly identical to what it takes to do this simple act.

---

As for my previous rant, I warned readers at the beginning I was going to rant. My frustration is partly with readers, but also with my own seeming inability to find a way to present this in a way you all will generally understand. I'm extremely visual, and text is too cumbersome at times. for some of the simplicities of concept. If you think my rant was long, I assure you the amount of text I would use is voluminous. Yet, I could give you the same in a drawing with a verbal explanation in about 45 seconds... see what I mean?

---

Finally, I want to thank Sorensen for pointing out the arbitrary limitation he was putting himself under. Perhaps by considering coding without such a limitation, he will see how this can be done, as will others of you. Developers aren't clever for nothing.

It doesn't matter what language you write in, you still have the same obstacles to overcome... learn to recognize when you are facing an artificial or even a language-imposed limitation over an actual physical limitation.

Try to understand the concepts without getting initially bogged down in the _details_, as this discussion went. You need to understand the concept first, and _then_ we can talk details.

Ciao,

Sorenson

Well I didn't think my initial post was patronizing. However, I can see how the tone may have changed as I was faced with ever-increasing inanity. Therefore, to the rest of you, I apologize. Be that as it may, I received nothing but arrogance from you.

As for portability, again, that's a compiler issue. doesn't matter what language you're working with. portability is merely about reliably converting compiler language into assembler to achieve consistent desired results on a set of platforms. The point is moot and has nothing to do with the language.

As for "no recent API" would use software rendering, you are flatly incorrect. Almost all high-end games support software rendering for compatibility. So do all current GUI-providing O/Ss. Since you are not writing ROMs for video hardware, for the sake of this exercise, you will _never_ do anything but software rendering. Again, your point is moot. I was simply providing a demonstration of the only method you're likely ever to work with.

As for "poorly behaved applications" versus "protected mode", from an O/S standpoint you have 2 kinds of applications-- "poor" and "good". Poorly behaved applications continually try to access addresses outside their heapspace-- this is indicative of poor pointer arithmetic, overrunns, etc. 'Protected Mode' was developed solely to try to curb this behavior by not allowing an application to do that. The O/S can't tell if the access is intentional or otherwise, so the 'protected mode' simply blocks all attempts. Therefore, if you _know what you are doing_, you can write a patch to the O/S to patch out that bypasses the code that makes up 'protected mode', thereby allowing you to access addresses you might otherwise be prevented from reaching.

---

Of the two of us, atleast I made the effort to provide an answer to the original poster. I will squander no more time and words on you, Sorenson.

WHEW!!!

As for "no recent API" would use software rendering, you are flatly incorrect. Almost all high-end games support software rendering for compatibility.

Well, if arguably the best writer of software renderers, John Carmack, abandoned them with Quake III (not really that new) I don't suppose there's much help for any of the rest of us. I'm not the worlds biggest gamer, but of the few that I've bought recently none run in software and all require a 3d accelerator. I'm not arguing that you shouldn't try though.

Of the two of us, atleast I made the effort to provide an answer to the original poster.

And I was pointing out that the original poster will have trouble if he is planning on developing or porting his app/game in/to a certain type of operating system using the methods you had described. Finally after persisting with this point (which you could have answered in your first subsequent post, if you hadn't gone off on one), you point out that that you can get around this limitation by patching your operating system, which is fair enough. If this is correct (and I don't doubt it is), then I concede it will be possible to write GUI/games using just C (assuming you can patch your o/s with just C).

However, I suspect this is not something that is done with any regularity by someone wishing to develop/port to this type of o/s.

I will squander no more time and words on you, Sorenson.

So be it.

swoopy,

I'll post some patch basics in another thread. pay no attention to sorenson, he's inexperienced. A sore loser, and feels he has to have the last word.

John Carmack chooses not to write his own code because he isn't interested in compatability. Carmack is solely focused on the ultimate performance. As far as he's concerned, he doesn't care about people who don't have the latest nvideo geForce 4 accelerator. It makes his job easier to code just to a hardware API standard.

Truly professional game-houses however, like say Infogrames, or Electronic Arts, etc., all support software rendering in most of their games. They are interested in a larger market, so compatibility is primary, and performance secondary.

The only difference between hardware versus software rendering is clockspeed. Almost everything else is generally identical.

And, something sorenson obviously is unaware of, is that when you write a software renderer, everything you display _also_ gets a small boost from the video accelerator.

> Therefore, if you _know what you are doing_, you can write a patch to the O/S to patch out that bypasses the code that makes up 'protected mode', thereby allowing you to access addresses you might otherwise be prevented from reaching.

Everyone on this board have fare more knowledge then I currently do but to pacth the OS doesn't really sound like the correct way to do things. Almost always when I have to fight my os/api it means that I am doing something wrong and need to rethink.

To the wizer ones who have not posted to this threat in an attack against me-- thanks. You guys are cool and not subject to the my ire.

To the sorenson and Quzah, again you are wrong on all your points. The problem is you didn't research far enough in any direction to find out.

Christ, I don't make this stuff up. It's experienced, it's lived. I mean, gee whiz-- Since Mechwarrior 4 didn't recognize my 32MB GeForce3 Ti 500 card in my 2.4GHz box, I thought it awfully interesting that it defaulted to software (but Daddy, it says 'accelerator required on the box!'). Too, amazingly, DirectX 8.x supports software rendering, that's why the DX diags tool tests for it... Oh, but I forgot, W2K and XP don't use DX8X... silly me.

Well, no matter. I'm doing it, you all are just talking about doing it. something that hasn't changed in the 5-6 years I've been coming here. While you all fiddle with the (heh, heh) intracacies of the 'if' statement, or work on mastering the difference between a short and a long, I will be doing something else great for the world.

riddance, I won't be back.

Hehe...

Might I ask what the fight is over? I've skimmed the thread and I just don't understand what you guys are making a big deal out of. What is the main point you people are arguing over?