Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 12 of 12
  1. #1
    Banned
    Join Date
    Apr 2017
    Location
    Texas
    Posts
    73
    Thanks
    16
    Thanked 4 Times in 4 Posts

    My software is a flop!

    I was trying to market my software however it was a flop. I don't know how people make money. I've been programming for 4 years straight and I collect welfare. I guess you can see that I am a starving artist of the programming genre. I remember hearing an old legend. He was playing the piano and making very little money living out on the streets. All he did was just played on the streets for people to see. Well he is still there however he makes money now!

    So here is the joke.

    I am here claiming to be an expert in programming of sorts. Yet when it comes down to it I only know the basics. I can program and get a game out but can't program in Windows except for a simple copy and paste sample. So that joke is on me. 4 years of straight programming and all I can get out in real Windows' programming is a simple hello by copying someone else's work and editing the content of the message!

    In essense I am stuck in the 80's. I program for an ancient language of MS DOS. In the year 2017 (30+ years later) the old MS DOS language is in use to this day.

  2. #2
    Administrator VIPStephan's Avatar
    Join Date
    Jan 2006
    Location
    Halle (Saale), Germany
    Posts
    10,751
    Thanks
    6
    Thanked 1,280 Times in 1,250 Posts
    Are you just letting off some steam or are you asking for help?

  3. Users who have thanked VIPStephan for this post:

    tienkhoanguyen (05-01-2017)

  4. #3
    Banned
    Join Date
    Apr 2017
    Location
    Texas
    Posts
    73
    Thanks
    16
    Thanked 4 Times in 4 Posts
    I'm asking for help. I was wondering how do you know it is time to make money? I was thinking of putting off selling my softwares until the last minute in exchange I would be a good programmer. I figure it is a trade-off. If you invest in making money you get the money however you don't know anything about programming. If you invest in making programming for happy life your life then you'll have very little to live off but are happy because you are doing what you want. However you need to balance that with supporting your family and that is a problem.

  5. #4
    Banned
    Join Date
    Apr 2017
    Location
    Texas
    Posts
    73
    Thanks
    16
    Thanked 4 Times in 4 Posts
    PingPong

    Specifically here is my software. Since it's not a success I'm giving it away. It is an ancient game plus a graphics editor that I made. That graphics editor has some value of interest.

    After reviewing my software you'll know why it's a flop. There's just something about it that is not sellable!

    Since I am the programmer. Any comment is welcomed. Thank you ahead of time!

    Even if the comment is something along the line that my programming is too fast or slow etc.

    Whatever you want to say about it.

    I figure I get feedback on what is not working.

  6. #5
    Banned
    Join Date
    Apr 2017
    Location
    Texas
    Posts
    73
    Thanks
    16
    Thanked 4 Times in 4 Posts

    Here is what is possible with my software alone.

    The attached image is originally changed through Photoshop CS2 to a bitmap format. This could also be done easily using Microsoft Paint. My software has a function I built through the knowledge of Jesus Christ inspiring me! It has curved the entire top row of characters into a ring around Jesus Christ's heart who is the savior of all people and the only one who can boast
    Attached Thumbnails Attached Thumbnails -test2-jpg  

  7. #6
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    2,156
    Thanks
    2
    Thanked 313 Times in 303 Posts
    Hey, I program for DOS too, but only for fun. You want to make money writing software, you're gonna have to big boy pants up and learn a modern language on modern platforms doing things people WANT... and to be frank, there's not a lot of genuine WANT for DOS games in 2017.

    You want to do it, you're going to have to learn and not just copy what others have done. Blind copypasta of off the shelf code isn't going to get you very far... THOUGH...

    Have you tried any modern quick to develop game environments like Unity or UDK?

    Unity is reasonably simple to start with, at least for making what we used to call shovelware. It's a bit more visual oriented than I care for personally, but it does let you target more than just one OS platform by abstracting the graphics calls -- so it can do DirectX, OpenGL, OpenGL ES, and Vulkan across Windows, Linux, OSX, iOS and Android. They have plenty of tutorials to help someone get started, and if you're SERIOUS about doing game development, there are far worse places you could start...

    ... because honestly screwing around in DOS, even if you use DOSBox as your distribution model, it's VERY unlikely you'll ever go past the 'novelty' stage of software. When I wrote Paku Paku it was more a exercise in the fun of pushing the hardware limits of an original 5150 than it was anything serious to make money. (hence it being released as cardware)

    I'm even still plinking away at a complete ASM rewrite instead of the hybrid Turbo Pascal + ASM it is now that's adding more sound card support -- but that's a for fun hobby project, not work.

    You want to make money, you're not going to do it in DOS.

    That said, I have a mental block from having written low level for so long, that I can't learn "visual programming" and I'd not be surprised if that's part of what's biting you. An intermediate learning step might be in order to transition you from the new to the old -- that's what it took for me about a decade ago to get over that hump. Using something like Free Pascal from the command line might be more your speed, and using simple interfaces like SDL with it might simplify the cross-platform gruntwork of accessing the hardware.

    The REALLY hard part is getting used to how modern graphics work, since raster graphics mentality is pretty much gone. In a LOT of ways it's more like working with sprites like on a commodore or Atari, but with a nearly unlimited number of them available. Putting out a 2d platformer for example MOST of the work is already done for you by the available graphics API. You're not going to sit there like you would in mode 13 manually writing your blitting routines, you're gonna tell SDL "Copy this image into the frame buffer" and then "show the next framebufffer". The idea of writing directly to the video RAM each byte? Yeah, that's GONE! Don't EVEN TRY! It violates the memory security policy in most modern OS...

    One of the reasons I liked Free Pascal for learning OpenGL/SDL is it's just a more clear language than C, and I was able to get my code to compile and run on both Linux and Windows with zero modification. Gets you into the modern API's and way of doing things whilst still having a very familiar 'old school' feel to it. SDL makes interfacing the keyboard, sound, and other input devices piss simple, and even lets you set the video mode and do simple 2d/raster operations. Once you have that down pat you can choose to run OpenGL on top of it for accellerated 3d if desired. PERSONALLY I found OpenGL easier to learn than DirectX, but if you're going to go low level you really should learn both.

    If you don't want to go that low level, that's what systems like Unity are for.
    I would rather have questions that can't be answered, than answers that can't be questioned.
    http://www.cutcodedown.com

  8. Users who have thanked deathshadow for this post:

    tienkhoanguyen (05-02-2017)

  9. #7
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    2,156
    Thanks
    2
    Thanked 313 Times in 303 Posts
    Just took a look... if you're going to give it away, including the source might be nice just for collaborative purposes or so others can teach you more about doing it... even for DOS games you've got problems like not latching the system timer, and really given the simplicity of these games your distro size is ridiculously massive.

    Even the DOS specific version being a 64k executable means you have likely greatly overthought how the code should work and/or are relying on compilers and libraries unsuited to the task.

    Just what languages/compilers are you using to build this? Apart from the (massive non-encoded) background image, being that it's VGA mode only in DOS I'm surprised that's more than a 16k executable... meaning it could/should just as easily have been done using the TINY memory model where DS=CS=SS.

    The not latching onto a timer is the real 'uh...' in there. Hooking the timer ISR and running it at specific intervals is a must-have for any game made after the introduction of the PC/AT.

    You should probably have something like this going on:

    Mind you, this code assumes a NEAR/TINY memory model which is sufficient for simple DOS games. The ISR stuff would have to remain near, if you want "far" change resetTimer, startTimer, endTimer and waitTimer to retf and callf. I'll comment the ones that would need changing for "far" memory models.

    Defines:
    Code:
    %define TIMER_60_ISR_RATE   19912
    ;  59.9225hz -- as close to 60 as we can get
    Data in CODE SEGMENT!
    Code:
    timer60_ticks            dw 0
    timer60_ISR_interval     dw TIMER_60_ISR_RATE
    ISR:
    Code:
    timer60_ISR:
    	inc  WORD [ cs : timer60_ticks ]
    	sub  [ cs : timer60_ISR_interval ], WORD TIMER_60_ISR_RATE
    	jc   .oldCall
    	push ax
    	mov  al, 0x20
    	out  0x20, al
    	pop  ax
    	iret
    	
    ; oldCall uses self modifying code
    .oldCall:
    	db 0xEA ; jmp
    directISR:
    	dd 0x00000000
    By decrementing the timer interval by the rate, we can smooth out the jitter to call the old timer ISR at its proper 18.2 times a second. Same basic concept as bresenham line-drawing math -- exploiting the rollover of fractions.

    Having a routine to reset the timer data is always handy:
    Code:
    resetTimer:
    ; ACCEPTS
    ;  nothing
    ; CORRUPTS
    ;  nothing
    ; RETURNS
    ;  YOU GET NOTHING!!!
    	mov  [cs : timer60_ticks], WORD 0x0000
    	mov  [cs : timer60_ISR_interval], WORD TIMER_120_ISR_RATE
    	ret ; retf for far model
    Then to set up the timer:

    Code:
    startTimer:
    ; ACCEPTS
    ;  nothing
    ; CORRUPTS
    ;  AX, BX, DX, ES
    ; RETURNS
    ;  nothing
    
    ; already running, skip out
    	cmp   [timer60_active], BYTE 0
    	ja    .done
    	inc   BYTE [timer60_active]
    	
    ; get old ISR address	
    	mov   ax, 0x3508
    	int   0x21
    	mov   [directISR], bx
    	mov   [directISR + 2], es
    	mov   dx, timer60_ISR
    	mov   ax, 0x2508
    	int   0x21
    	cli
    	call resetTimer ; callf for far model
    	; set new ISR speed
    	mov   bx, TIMER_60_ISR_RATE
    	mov   al, 0x34
    	out   0x43, al
    	mov   al, bl
    	out   0x40, al
    	mov   al, bh
    	out   0x40, al
    	sti
    .done:
    	ret ; retf for far model
    Naturally this also needs a routine that on shutdown returns the PIT to its normal behavior:

    Code:
    endTimer:
    ; ACCEPTS
    ;   nothing
    ; CORRUPTS
    ;   AX
    ; RETURNS
    ;   nothing
    	cmp [timer60_active], BYTE 0x00
    	je  .done
    	cli
    	; turn off speaker before we start playing with timers!
    	; laughably if left on after exit, can crash dosbox?!?
    	in   al, 0x61
    	and  al, 0xFC
    	out  0x61, al
    	in   al, 0x61
    	and  al, 0xFC
    	out  0x61, al
    	mov  al, 0x34
    	out  0x43, al
    	; timer rate of 0 is actually 65536.
    	; 1.193182mhz PIT master clock / 65536 == roughly 18.2hz
    	xor  ax, ax
    	mov  [timer120_active], al
    	out  0x40, al
    	out  0x40, al
    	push ds
    	lds  dx, [directISR]
    	mov  ax, 0x2508
    	int  0x21
    	pop  ds
    	sti
    .done:
    	ret ; retf for far model
    What all this does is speed up the PIT - programmable interrupt timer -- from the normal 18.2 times a second to 60 times a second, whilst ON AVERAGE still calling the original timer ISR 18.2 times a second. Mind you that's on average, so it's NOT precise, but it's close enough for every major commercial game ever written after ~1984 or so for DOS.

    You would call startTimer to set it up, and be sure that your exit handler or chain calls endTimer, EVEN on error.

    Then your main loop of your game would call this:
    Code:
    waitTimer:
    ; ACCEPTS
    ;   nothing
    ; CORRUPTS
    ;   AX
    ; RETURNS
    ;   AX  number of loops waited
    	xor  ax, ax
    .loop:
    	sahf
    	js    .cmpCounter
    	inc   ax
    .cmpCounter:
    	cmp   [timer120_ticks], WORD 0
    	je    .loop
    	dec   WORD [timer120_ticks]
    	mov   [timer120_waited], ax
    	ret ; retf for far model
    Which waits for that timer tick to fire before continuing. End result, your game will lock to 60FPS or less regardless of what speed CPU you are running on... at least in DOS. Naturally in Windows you would use a timer event.

    Notice my sahf trick. This prevents it from looping more than 32k times since at that point it's possible the timer event isn't firing. On REALLY fast (4ghz+) machines this could fail, but really what 4ghz plus machine is going to be running DOS native?!? At that point run it in DOSBox.

    The return of loops waited is only decremented by one so that SHOULD you have a timeslice take longer than needed, it will run flat out until the code catches up. This is handy at faster time-slice rates (my own games run at 120 ticks so I can do 20fps, 24fps, and 30fps off a single timer for different level speeds, whilst updating audio at 120) where you might end up creating cooperative multitasking to smooth out things like screen drawing or have consistent music playback speeds.

    Oh, and ease up on the Jesus thing...

    1) the background image makes it hard to see the ball

    2) that can alienate a lot of people who don't subscribe to that particular flavor. Far too many people will go "oh look, another Jesus freak" and not even bother going further/deeper than that. Regardless of which fairy tale one follows, you should never limit your audience by slopping your faith into a product. You'll just end up laughed at like the guy making "TempleOS". That's harsh, but that's reality.

    Remember religion is like having a *****. It's ok to have one, just don't go waving it in people's faces uninvited.

    You may also want to try something a bit more ambitious than Pong... given what you have there might as well be out of the "beginning integer BASIC" book for the original Apple II. I mean, we all start somewhere, but even for DOS based game writing you're barely out of the gate. I mean to be frank, I've seen more advanced games written using qbasic.

    No offense, but that's the truth of it.

    Now, I'm willing to help you learn, but we've got to get you up to speed on more advanced game development and hardware interfacing concepts before we even talk about more advanced development PLATFORMS.
    I would rather have questions that can't be answered, than answers that can't be questioned.
    http://www.cutcodedown.com

  10. Users who have thanked deathshadow for this post:

    tienkhoanguyen (05-02-2017)

  11. #8
    Banned
    Join Date
    Apr 2017
    Location
    Texas
    Posts
    73
    Thanks
    16
    Thanked 4 Times in 4 Posts
    Hey deathshadow. Your code name really sucks but I like your real name. So go figure. haha Anyways thanks for being up front with me. I know my religion shouldn't be shovered down people's face each time they see my demo. However it is how I express myself. Well what you were talking about in DOS. thanks again. I need a lot of lessons. A lot in sounds. A lot all around. Like you already know I am just barely out of the gates. 4.5 years programming is just barely graduating. Only 5 months on the job is nothing. haha Anyways I will have to think long and hard before learning anymore right now. However I will look it over since I have the time.

  12. #9
    Banned
    Join Date
    Apr 2017
    Location
    Texas
    Posts
    73
    Thanks
    16
    Thanked 4 Times in 4 Posts
    I did the TSR thing 4 years ago however I threw it out because I was going mainstream. I just wanted to have people's trust so I never messed with TSR again since it could easily become an embedded virus. Anyways. I can't believe I have forgotten everything almost about TSR!!! I went from making my own program detect a keypress and activating my program to forget me.

  13. #10
    Banned
    Join Date
    Apr 2017
    Location
    Texas
    Posts
    73
    Thanks
    16
    Thanked 4 Times in 4 Posts
    Just to let you know you should have probably kept your source code! Stuffs like that are always in demand. I didn't look at any of anyone's source code since I started because I always had pride in my stuffs# The only thing I looked at was textbooks when I was learning. Then I developed much of the source codes and theories for myself. JESUS if it wasn't for my parents drilling me to learn I would have sank.

  14. #11
    Banned
    Join Date
    Apr 2017
    Location
    Texas
    Posts
    73
    Thanks
    16
    Thanked 4 Times in 4 Posts
    I'm not that experienced compared to you. 30 years or so is a long time. I have 35 years however it was periodically done.

  15. #12
    New to the CF scene
    Join Date
    Apr 2017
    Posts
    1
    Thanks
    0
    Thanked 0 Times in 0 Posts
    In the end, I lost myself in this end. But maybe I needs more time to learn and then I will understand everything at once. Jokes don't joke, it's time to get to work!
    Last edited by vinyl-junkie; 05-05-2017 at 06:56 PM. Reason: advertisting/self-promotional link removed


 

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •