quote: 1.There is no overhead with messages/objects and stuff 2.You can use hardware directly 3.16bit code is MUCH faster then 32 bit code 4.You can disable interupts when needed for speed DOS IS HARDER TO PROGRAMM..... because 1.Almost all new hardware have drivers only for Windows 2.You must know more about hardware and generaly programs are not compatible with all hardware 3.You dont have 32 bit huge linear memory adress or if you have it *via a dos extender, you have to know things about slectors and Global descriptor tables...so not very easy again 4.Even if its more faster its not commercial anymore to make programms for DOS.... you have to do it for windows or evantualy unix if you want to make money from it
Compressing........................100% done
Let''s just take the main reasons:
<br>There <b>aren''t </b> any drivers for DOS<br>You can''t disable interrupts forever<br>Very few people uses DOS today. The few that do usually don''t have the necessary hardware for today''s games.<br>Acessing hardware directly is no fun if you have to write a "driver" for every type of board in the market.<br>
Ya know what? DirectX isnt as fast as DOS. Windows98 is slower than Windows95. C++ is slower than Assembly. Guess what? I can write a program in Direct3D in 1/1000 the time it would take to write THE EXACT SAME thing on a DOS platform. I can use about a million things much easier in win98 than win95. I can write anything in C++ in 1/1000 the time it would take in ASM. Guess what? Thats the way it works. As you make things that require more processor time, are easier to use, and consume more RAM, you give up a bit of speed. Its the way it works. Thats why we have 1000 MHz CPUs and gigabytes of RAM. You cant expect that system requirements are ever going to remain the same (yes, I think most programs dont do enough things right, but thats beside the point). There is no way that you can honestly tell me that a program that incorporates Phong shading, full transparency effects, Thousands of online players, and millions of polygons will run at the same speed as a 2D side scroller. Yes, I have seen programs written in full ASM that perform full 3D on <33MHz PCs. In fact, I saw a demo of a goroud shaded cube, running at 70 FPS on a 386. The author wrote it in appoximately 2 weeks. I can do the same in D3D in about 5 minutes.(thats including compile time and initializing D3D) Thats also the point of new hardware. It gives us the capability of doing many things that were too cumbersome or time consuming before. If it werent for the advances in software, hardware wouldnt evolve, and vice versa. Would you really want to be stuck writing your own drivers for every piece of hardware that becomes available on the market? In order for the games to be produced on a timely schedule, something would need to be sacrificed, and as sad as it is, that something is much more likely to be gameplay than graphics quality. If you really want to, go ahead and write directly in Binary(im sure you can go much faster with that) but in 3 years, when you finally have that cube rotating, come tell me how much better it is.
What is a man without goals? A dead man.
---------------------------Hello, and Welcome to some arbitrary temporal location in the space-time continuum.
I think that there should be a program that runs in pure DOS and acts and acts like an emulator - except it''s not emulating any existing system and there are some drivers written for it. Programmers would use a special compiler to write programs for it. Then, with the right coding, your computer would become a console system, like the N64 or Playstation. Instead of having to port each game written, you just port the "emulator" to each system.
Even better, if someone made a boot disk that went straight to this program instead of Windows, you put in your emulator boot disk, put in the CD, and just turn on your computer. Sounds good, huh?
Before you say it: Yeah, I know there will be speed losses. But some clever program COULD turn the universal program into specific machine code temporarily, right?
If you were writing a game to run solely on one spec of PC (e.g. your own), you could write it in DOS provided you have the necessary documentation for all your hardware you wish to access.
IN THE REAL WORLD you want to write something that can be run on as many PCs as possible (I hope!!!), which can involve an almost infinite number of combinations of processor/memory/video/sound/network/modem etc.etc.etc.
In the days before DirectX, you had to write your game to deal with as many types of hardware as possible (a mammoth task!!!) to make your product as widely compatible as possible.
Fortunately for you (and me), those guys at Microsoft took this problem away from us, and created the DirectX API. This isolates us from the myriad of hardware possibilities, and provides us with a high performance common interface.
As a result, there is a turnaround in who has the hard work. Rather than us trying to write games that are compatible with all hardware, the hardware manufacturers need to develop their own set of DirectX drivers (using the DirectX DDK) if they want their product to be compatible with your game (written in DirectX).
Another bonus of this model is that DirectX has a layer called HEL (Hardware Emulation Layer). This overcomes the shortcomings of any hardware by emulating the API call via software. This (although I''ve never tried it) means that a game written using Direct3D will work on a straight 2D only card. Any 3D acceleration available will be utilised (and lighten the burden on the main CPU).
If you opt for DOS over DirectX, good luck. You''ll need it...
HEL layer is really HELL!!. Very slow and not 100% 3d capable. If you don''t have a good 3d card, many function will not be usable. The game programming will does this function (if allowed). DOS is very fast!!. Many 386/486 2d/3d games (without 3d card) run at same speed with a Win-games with a pentium. But DOS is dead!!, because of HW drivers. But still you use the DOS (or the same functions) via assembler in a win-apps. Plus directx lock system will does as speed process.
OpenGL portable... yes of course, but the work to translate Apps from Win to Unix is about of 30% of new code. Plus the new bugs in this version.. (Opengl-win is "same" not equal to Opengl-other ports) will does to recreate more code. The data manager (pictures, music), will be rewrite and repacket. So, in total :portable will work in about 50% plus of new work (in code, in artistic work is about of 5% or 0%).
-----------------------------------------------"Cuando se es peon, la unica salida es la revolución"
