- Forum
- General C++ Programming
- near and far with C++
near and far with C++
Hi,
I'm working with Turbo C++, trying to make a DOS game. In C, if I wanted to allocate memory, I'd have to specify whether I wanted to use far or near memory using farmalloc and malloc respectively. In C++ however, I'd want to use "new" to allocate memory, but I'm not sure exactly how this would work in DOS with its wierd memory model. Has anyone got a clue about this? I tried googling but everything is about C and not C++.
Why am I doing a DOS game? for fun and learning about graphics. Why am I not using a modern DOS compiler like DJGPP? because that's not retro enough :P (it generates 32bit code, not 16bit, so no wierd memory models, for one) but I am very tempted to switch now that I discovered many quirks in Turbo C++. This is the latest quirk.
Thanks!
EDIT: I can always switch to the huge memory model and not have to worry about near/far pointers I think, but then I might as well move to DJGPP :P
I'm working with Turbo C++, trying to make a DOS game. In C, if I wanted to allocate memory, I'd have to specify whether I wanted to use far or near memory using farmalloc and malloc respectively. In C++ however, I'd want to use "new" to allocate memory, but I'm not sure exactly how this would work in DOS with its wierd memory model. Has anyone got a clue about this? I tried googling but everything is about C and not C++.
Why am I doing a DOS game? for fun and learning about graphics. Why am I not using a modern DOS compiler like DJGPP? because that's not retro enough :P (it generates 32bit code, not 16bit, so no wierd memory models, for one) but I am very tempted to switch now that I discovered many quirks in Turbo C++. This is the latest quirk.
Thanks!
EDIT: I can always switch to the huge memory model and not have to worry about near/far pointers I think, but then I might as well move to DJGPP :P
Last edited on
You can check your compiler documentation, but I'm sure that new will return a far pointer.
You _really_ should switch to a modern OS though. When I switched to 32 bit programming
using a flat memory model, I never went back to the segmented DOS days. It's just a
headache.
You _really_ should switch to a modern OS though. When I switched to 32 bit programming
using a flat memory model, I never went back to the segmented DOS days. It's just a
headache.
Deliver me from 1992.
The only good answer to that question =D
I'm a active DOS hating machine, but when it comes down to it, any project that is fun is worth doing, IMO. Even if it's otherwise pointless.
The problem with this is that anything you learn about graphics is ultimately obsolete as modern graphics have pretty much nothing in common with retro DOS-era graphics.
That and you're stuck having to learn a bunch of other really weird stuff that has no place in modern programming (like the question you're actually asking about)
As for your actualy question. Sorry, but I haven't a clue =(
| Why am I doing a DOS game? for fun |
The only good answer to that question =D
I'm a active DOS hating machine, but when it comes down to it, any project that is fun is worth doing, IMO. Even if it's otherwise pointless.
| and learning about graphics |
The problem with this is that anything you learn about graphics is ultimately obsolete as modern graphics have pretty much nothing in common with retro DOS-era graphics.
That and you're stuck having to learn a bunch of other really weird stuff that has no place in modern programming (like the question you're actually asking about)
As for your actualy question. Sorry, but I haven't a clue =(
Ah... The nostalgia filter.
Sorry to be repetitive, but really. Don't do this. We have enough 16-bit code to interface with as it is. We don't need more. Modern hardware and OSs won't even run 16-bit code except through virtualization, so why you'd want to punish your users (even if it's only yourself) for no good reason is beyond me.
You can still write a retro-looking game without having to resort to voodoo programming. It's all about how it's rendered, not what kind of memory addressing the underlying code uses. Nowadays, code isn't even bound to any register size. Porting code back and forth between 32- and 64-bit (and beyond) machines is routine. Any 16-bit code you write becomes useless the moment you type it.
Sorry to be repetitive, but really. Don't do this. We have enough 16-bit code to interface with as it is. We don't need more. Modern hardware and OSs won't even run 16-bit code except through virtualization, so why you'd want to punish your users (even if it's only yourself) for no good reason is beyond me.
You can still write a retro-looking game without having to resort to voodoo programming. It's all about how it's rendered, not what kind of memory addressing the underlying code uses. Nowadays, code isn't even bound to any register size. Porting code back and forth between 32- and 64-bit (and beyond) machines is routine. Any 16-bit code you write becomes useless the moment you type it.
TurboC++ does huge memory models just fine, but you may find that a "medium" memory model will work for what you want...
hmm.. I guess I should switch to DJGPP then. Will remove a lot of headaches, like the basic idea of far/near pointers :P and I also realized that Turbo C++ doesn't support exceptions or namespaces (including the std namespace), among other things. Plus having a 32bit program will probably give me more memory (more than 1MB at least)
Well, I dont know much about today, but in DOS, the only thing you get is a huge array that basically accts as your screen. No "drawLine" or "drawSprite" functions.. you're going to have to implement that yourself. And that's what I find appealing in this.
and helios, I don't really care if it's going to be useful or not. In fact it's not supposed to be useful since it's a game :P One of my plans when i finish this game is to put it in a DOS boot disk, and then have my friends play by booting from the floppy drive and actually running it. How awesome is that? :D
Well, I dont know much about today, but in DOS, the only thing you get is a huge array that basically accts as your screen. No "drawLine" or "drawSprite" functions.. you're going to have to implement that yourself. And that's what I find appealing in this.
and helios, I don't really care if it's going to be useful or not. In fact it's not supposed to be useful since it's a game :P One of my plans when i finish this game is to put it in a DOS boot disk, and then have my friends play by booting from the floppy drive and actually running it. How awesome is that? :D
I personally found it fun to program under DOS. Playing with the graphics hardware is what got me into programming to begin with.
I don't see why not use Turbo C++... It is an older compiler, written before C++ was standardized, so naturally you must use an older version of the language.
Of course, I have a strong dislike for DJGPP... but that is my own personal bias.
I don't see why not use Turbo C++... It is an older compiler, written before C++ was standardized, so naturally you must use an older version of the language.
Of course, I have a strong dislike for DJGPP... but that is my own personal bias.
I would rather use an old compiler than a modern one really, but as long as the old compiler supports at least a slightly modern implementation of C++
I wonder if there's a newer version of Turbo C++ or perhaps any other compiler that compiles 16bit code, and yet supports all the newer stuff that C++ has (like exceptions and strings and namespaces)
I kept a back-up copy of my code just in case I fail miserably at porting it to DJGPP. So far it's going well and right now the only barrier left is linker errors :/ I hate linker errors.
I wonder if there's a newer version of Turbo C++ or perhaps any other compiler that compiles 16bit code, and yet supports all the newer stuff that C++ has (like exceptions and strings and namespaces)
I kept a back-up copy of my code just in case I fail miserably at porting it to DJGPP. So far it's going well and right now the only barrier left is linker errors :/ I hate linker errors.
| and helios, I don't really care if it's going to be useful or not. In fact it's not supposed to be useful since it's a game |
| One of my plans when i finish this game is to put it in a DOS boot disk, and then have my friends play by booting from the floppy drive and actually running it. How awesome is that? |
helios, I was under the impression that you were talking about usefulness.
Additionally, if one wants to play it safe, they can always use dosbox. it runs on several platforms (I'm using linux).
I understand that a retro-looking game can be made using modern tools and platforms since it's all about how stuff are rendered. Yet I am still interested in how old platforms used to do the job, even if nobody's using it anymore, which is the reason I'm making this game.
As for the disk sectors getting over-written.. well... I'm just going to have to make sure that it doesnt do that :P
Additionally, if one wants to play it safe, they can always use dosbox. it runs on several platforms (I'm using linux).
I understand that a retro-looking game can be made using modern tools and platforms since it's all about how stuff are rendered. Yet I am still interested in how old platforms used to do the job, even if nobody's using it anymore, which is the reason I'm making this game.
As for the disk sectors getting over-written.. well... I'm just going to have to make sure that it doesnt do that :P
closed account (S6k9GNh0)
ASM isn't retro and is still used all the time by itself.
DOS uses an old memory model that isn't similar to any modern OS. Most compilers that work on DOS are completely different from that of those on Windows, Linux, etc.
DOS is very insecure at the user level. You can access anything you want, there is no security @ the kernel level. I'm actually talking from knowledge, not from experience, I've never used DOS nor would I have ever. The main advantage of DOS is that its fast. Very fast. I've always wanted a gaming OS that most games would use similar to DOS with a better interface. I would like an OS that would only use one program at a time, similar to how the Xbox runs. If that were to be implemented and game manufacturers would use it, our computers would be absolute gods at games. My computer can only run Crysis at full detail with AA x 4 and 1920 x 1080 resolution @ 60 fps (limited by monitor refresh rate). Think about how well it would do if we took away everything else besides the game and dedicated the entire rig to that specific game. Of course, this method isn't convenient for multitasking at all.
DOS uses an old memory model that isn't similar to any modern OS. Most compilers that work on DOS are completely different from that of those on Windows, Linux, etc.
DOS is very insecure at the user level. You can access anything you want, there is no security @ the kernel level. I'm actually talking from knowledge, not from experience, I've never used DOS nor would I have ever. The main advantage of DOS is that its fast. Very fast. I've always wanted a gaming OS that most games would use similar to DOS with a better interface. I would like an OS that would only use one program at a time, similar to how the Xbox runs. If that were to be implemented and game manufacturers would use it, our computers would be absolute gods at games. My computer can only run Crysis at full detail with AA x 4 and 1920 x 1080 resolution @ 60 fps (limited by monitor refresh rate). Think about how well it would do if we took away everything else besides the game and dedicated the entire rig to that specific game. Of course, this method isn't convenient for multitasking at all.
Last edited on
| As for the disk sectors getting over-written.. well... I'm just going to have to make sure that it doesnt do that :P |
| I would like an OS that would only use one program at a time, similar to how the Xbox runs.If that were to be implemented and game manufacturers would use it, our computers would be absolute gods at games. |
Also, PCs are and have been the gods of gaming for a long time. They produce more detailed graphics at higher framerates (at least twice, under normal operation). This is expected. A high-end PC has at least six processors (four CPU cores and two GPUs, and GPUs can have hundreds of internal cores). If it wasn't much, much faster than a console then there would be something terribly wrong with the world.
Console games aren't typically faster because of some software magic. They're faster because console hardware is designed for games. PCs have huge memories connected by narrow buses, while consoles have wide buses that connect relatively small memories. The design used in PCs works well for general purpose computation, where many different operations are applied to the same set of data, but it needs much bigger memories to compensate for "streaming" applications, where a few operations are applied to large sets of data, such as games, video playback, etc.
http://arstechnica.com/old/content/2000/04/ps2vspc.ars/1
closed account (S6k9GNh0)
I actually remember reading up on the amazing piece of hardware called the N64. Very interesting and takes hardware to the limit during that time for games (at a reasonable price of course). It really does make me wonder if I would ever be able to take up their shoes and implement something similar to that. As we move up on the scale, we actually move very close to the common place PC modified (heavily) for games. I, however, find it difficult to understand all of these concepts and I'm rather confused by a lot of it despite having dove deep into it for years. When I get into college, I plan on dedicating myself to these concepts and understanding them along with the software that takes full advantage of these concepts.
Back onto this topic, I always figured it was at least partially software. On a common place OS for browsing, i.e. Window, you have an average 60+ processes running in the background often unrelated to your game (except maybe the processes that handle sound and a few other OS related processes). Although the game often gets higher priority over the CPU than other applications, it still gives processing time to all of the other processes in the background.
Back onto this topic, I always figured it was at least partially software. On a common place OS for browsing, i.e. Window, you have an average 60+ processes running in the background often unrelated to your game (except maybe the processes that handle sound and a few other OS related processes). Although the game often gets higher priority over the CPU than other applications, it still gives processing time to all of the other processes in the background.
How many processes are running in the background doesn't by itself affect CPU performance, only memory usage. Most of those processes are most of the time waiting for Sleep() to return, or waiting for some synchronization event, or anything of that sort. Even if the system didn't implement priorities and you had 100 processes running, one of them that needs a lot of CPU time can run as smoothly as if it was the only one running. It's not priorities or number of running processes that matters, it's how much time all the processes are actually using. A process that yields uses practically no CPU (it's a very small fraction of the timeslice).
Topic archived. No new replies allowed.