Re: A new commercial game for MS-DOS
Posted: Mon Jul 09, 2012 4:16 am
Sorry, but that rationale while great for a hobby project does not a commercial venture make.
The Place to Start for Operating System Developers
https://f.osdev.org/
My problem is that these real mode code bytes and programming techniques are interesting by themselves.turdus wrote:Imho you should use some kind of scripting engine for your goals, like ScummVM. You can include a plugin for your data format if you like, or use one of Lucas Arts'. This vm runs old MS-DOS games (among others), so you'll have the same feeling without coding a single real mode code byte. Still have to design the game and look-and-feel though, which will be costy.
If your using DOS on a physical machine well that statement logically can't be possible. Although if you use it on a emulator such as DOS box you can make the setting high. That's what this guy did and he even used OpenGL! http://www.youtube.com/watch?v=vkUwT9U1GzAhigh-quality gamehigh-quality game
Well sorry but the odds of that project working are low unless you ported to a phone or tablet like posts have been saying. The reason is DOS is a legacy/retro operating system therefore most people who use it retro lovers which BTW there is a big market for retro games.The word "retro" is _not_ used anywhere
Well unless you are going to port it to a phone/tablet people aren't going to wan't to spend the money. Also why not make it open source because there are plenty of commercial open source apps, games, and os's. ex. Red Hat.The open-source-hobby-project feel and appearance should be strictly avoided
There are so much more than a resolution or effects that define "the high quality game".sds2017 wrote:If your using DOS on a physical machine well that statement logically can't be possible. Although if you use it on a emulator such as DOS box you can make the setting high.
I liked very much the pixelated look of the walking scene.sds2017 wrote:That's what this guy did and he even used OpenGL! http://www.youtube.com/watch?v=vkUwT9U1GzA.
As much as I like the open source in general, I did not include it in this concept. However, the open source game engine ports would be reasonable. The game data is the actual proprietary content and how the data is interpreted is secondary case. However, for me it is primary because I am technically oriented. A little bit confusing?sds2017 wrote:Also why not make it open source because there are plenty of commercial open source apps, games, and os's. ex. Red Hat.
Agreed. I like the old games better. They've provided a low quality visual, that's true, but that was compensated by marvelous game ideas and unbelievable programming techniques.Antti wrote:There are so much more than a resolution or effects that define "the high quality game".
No, not confusing at all, and it's not your idea. That's exactly how ScummVM work. And pretty much that's how every other Linux game work (just a few example: Doom, Quake, or Duke Nukem 3D. All of these howtos share one thing in common: "copy game data from purchased DOS version to your Linux box").As much as I like the open source in general, I did not include it in this concept. However, the open source game engine ports would be reasonable. The game data is the actual proprietary content and how the data is interpreted is secondary case. However, for me it is primary because I am technically oriented. A little bit confusing?
It was not my idea but I would had ruthlessly used the same approach. My idea (hopefully) would had been to create "a classic MS-DOS game" in this decade. I did mention the "like abandonware" aspect so basically it would had been free to use (but still proprietary). Some commercial success might had happened in phone/tablet ports. The MS-DOS game just being the start of the game brand.turdus wrote:No, not confusing at all, and it's not your idea. That's exactly how ScummVM work. And pretty much that's how every other Linux game work (just a few example: Doom, Quake, or Duke Nukem 3D. All of these howtos share one thing in common: "copy game data from purchased DOS version to your Linux box").
What I was trying to tell you with the ScummVM example is that your goal does not fit in a profit oriented project. There's no point in expecting money on a end-of-life OS. It's only the non-profit community behind that keeps 16 bit running. Even if they won't be pissed at you, and they are willing to buy your game, it's a not a big share of the market, isn't it?
It is possible to use SDL with HX Dos Extender. (On this way you could even run DOSBox in DOS)bluemoon wrote:Cross-platform library for windows, mac, linux is fairly easy due to POSIX and OpenGL; crossing with DOS is non-trivial, DOS simply has nothing. I'm not saying it is impossible, it's actually doable and not difficult, but I'm certain it double the workload.
Anyway, good luck.
MasterLee wrote:It is possible to use SDL with HX Dos Extender. (On this way you could even run DOSBox in DOS)
That's interesting. If I wanted to do a system just for playing MS-DOS games with moderd hardware, this would be worth considering to. It would probably boot very quickly.http://www.japheth.de/HX.html wrote:Running DOSBox in DOS with HX is not that senseless as it might seem at first glance.
I use the bios option "USB lagacy enable" for to become the mouse-informations of a USB-mouse like a PS2-mouse from the keyboard controller. (No USB-driver needed for an USB-mouse using DOS.)bluemoon wrote:Another challenge with write DOS game on modern machine is drivers.
You need ...mouse.....
Code: Select all
START:
CHECKPS2: int 11h ; get equipment list
test al, 3
jz short NOPS2 ; jump if PS/2-Mouse not indicated
mov bh, 3 ; data package size (1 - 8 bytes)
mov ax, 0C205h
int 15h ; initialize mouse, bh=datasize
jc short NOPS2
mov bh, 3 ; 03h eight counts per mm
mov ax, 0C203h
int 15h ; set mouse resolution bh
jc short NOPS2
mov ax, cs
mov es, ax
mov bx, OFFSET PS2TEST
mov ax, 0C207h
int 15h ; mouse, es:bx=ptr to handler
jc short NOPS2
xor bx, bx
mov es, bx ; mouse, es:bx=ptr to handler
mov ax, 0C207h
int 15h
ret
NOPS2: stc
ret
;----------------------------------------------------------------------------
PS2ON: call PS2OFF
mov ax, cs
mov es, ax
mov bx, OFFSET PS2IRQ
mov ax, 0C207h ; es:bx=ptr to handler
int 15h
jc short NOPS2
mov bh, 1 ; set mouse on
mov ax, 0C200h
int 15h
ret
;-------------------------------------
PS2OFF: xor bx, bx ; set mouse off
mov ax, 0C200h
int 15h
xor bx, bx
mov es, bx
mov ax, 0C207h ; es:bx=ptr to handler
int 15h
ret
;----------------------------------------------------------------------------
org START + ((($-START)/16)*16)+16 ; we want a code alignment
;----------------------------------------------------------------------------
PS2IRQ: push ds
pusha
mov ax, DATEN
mov ds, ax
mov bp, sp
mov bx, [bp+22+6] ; status byte(buttons,Sign,Overflow)
mov cx, [bp+22+4] ; X movement
mov dx, [bp+22+2] ; Y movement
mov ax, [XACK]
test bx, 10h ; Sign X Mouse goes right
jz short MOGOR
neg cl
sub ax, cx
cmp ax, [BHMIN] ; (Hmin) Mouse-pointer to much on the left side?
jb short IY0
; test bx, 40h ; Overflow X
; jz short IY0
IX1: jmp short IX2 ; write X
;---------
MOGOR: add ax, cx
cmp ax, [BHMAX] ; (Hmax) Mouse-pointter to much on the right side ?
ja short IY0
; test bx, 40h ; Overflow X
; jz short IY0
IX2: mov [XACK], ax
;---------------------------------
IY0: mov ax, [YACK]
test bx, 20h ; Sign Y Mouse goes down
jnz short MOGOU
sub ax, dx
cmp ax, [BVMIN] ; (Vmin) Mouse-pointer to high ?
jb short IIZ
; test bx, 80h ; Overflow Y
; jz short IIZ
IY1: jmp short IY2 ; write Y
;---------
MOGOU: neg dl
add ax, dx
cmp ax, [BVMAX] ; (Vmax) Mouse-pointer to deeply ?
ja short IIZ
; test bx, 80h ; Overflow Y
; jz short IIZ
IY2: mov [YACK], ax
;---------------------------------
IIZ: and bx, 3 ; only buttons, remove Sign + Overflow
mov [TACK], bx
;---------
popa
pop ds
PS2TEST: retf
;--------------DS-SEG----------
XACK DW MXpos ; Mouse X
YACK DW MYpos ; Mouse Y
TACK DW 0 ; Button,Sign,Overflow
BHMAX DW Hmax ; Mouse limits
BHMIN DW Hmin
BVMAX DW Vmax
BVMIN DW Vmin
Thank you for your offer. However, I am not very interested in this idea anymore. Enthusiasm is very important if doing something like this and I do not have it enough. It is also because I have no necessary skills for this (programming or business). If I had, I am sure we could get things rolling. With high quality teasers like pixel-art "screenshots", it would definitely be possible to attract attention and get more developers for the team.cassioraposa wrote:Antti, I'm not an OS hobbyist but I'm skilled in pixel-art and audiovisual game resources in general. Should you want to team up in your project, just PM me, k?