REQ: RollBall update - OS2

This is a discussion on REQ: RollBall update - OS2 ; Can http://hobbes.nmsu.edu/pub/os2/games...n/rollball.zip be fixed, so it'll work with both modern computers and 1992-ones? Full source is included, overloaded with comments. IBM C Set/2 makefile present. Just a longer period of DosSleep() and a recompile may be needed here? The executing ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

Thread: REQ: RollBall update

  1. REQ: RollBall update


    Can http://hobbes.nmsu.edu/pub/os2/games...n/rollball.zip be fixed,
    so it'll work with both modern computers and 1992-ones? Full source is
    included, overloaded with comments. IBM C Set/2 makefile present. Just
    a longer period of DosSleep() and a recompile may be needed here? The
    executing speed seems to be the only problem.

    FWIW: modifying is allowed, and it may be useless nowadays to honour a
    mentioned request to distribute both the outdated original version and
    the fixed version.



    ---

  2. Re: REQ: RollBall update

    On Fri, 25 Jul 2008 18:18:39 UTC, gamer@gam.esPAM (AI) wrote:

    >
    > Can http://hobbes.nmsu.edu/pub/os2/games...n/rollball.zip be fixed,
    > so it'll work with both modern computers and 1992-ones? Full source is
    > included, overloaded with comments. IBM C Set/2 makefile present. Just
    > a longer period of DosSleep() and a recompile may be needed here? The
    > executing speed seems to be the only problem.
    >
    > FWIW: modifying is allowed, and it may be useless nowadays to honour a
    > mentioned request to distribute both the outdated original version and
    > the fixed version.


    I'm downloading it right now. Do you believe I never heard about it?
    What is this game about?

    Mentore

  3. Re: REQ: RollBall update


    >> Can http://hobbes.nmsu.edu/pub/os2/games...n/rollball.zip be fixed,
    >> so it'll work with both modern computers and 1992-ones?


    > I'm downloading it right now. Do you believe I never heard about it?


    I do! Many moons ago, in the "OS/2 Games"-section of about any ancient
    OS/2 BBS it probably would be listed in the Top-10. Just because there
    were no more than 10 OS/2 PM games available? Today I saw the "known"
    name of this game again, somehow vaguely knew it was useless, installed
    it anyway just to having about anything kept installed, and I nearly
    missed the existence of the source due to it being recorded here as
    shareware (and in 1992 open sourcing wasn't invented yet?).

    > What is this game about?


    Right now about an extremely fast red dot instead of rolling ball, soon
    followed by a message stating you scored X point. :-)

    Section of ROLLBALL.DOC:

    ----------------------------------------------
    RollBall is game of my proprietary design. The goal of any player is, to roll
    RollBall (the red moving circle) of points (the colored circles) to get
    points. RollBall will be reflected by the borders of the playing ground (the
    borders of the Presentation Manager window), and deflected by the deflectors,
    the / and \ symbols.
    But beware of the holes (the black surronded dark circles), if you get in
    contact with one, you lose your life.
    Points, deflectors and holes randomly disappear and appear. Rolling over any
    point or deflector also removes them. To place a deflector, you use the mouse.
    The left mouse butten will place a \ deflector, and the right button will
    place a / deflector.

    I developed this program in about 3 Weeks in August. Because this is my first
    try to program the Presentation Manager there may and will be some bugs.
    ----------------------------------------------

    Not that spectacular, but it seems like an easy rescue operation to me.
    If you really want to go nuts with, you could e.g. replace the old OS/2
    logo with an eCS logo, but without having PM programming experience
    I'ld guess the only thing really required to safe it is a delay, so it
    will no longer be too fast with computers outperforming a 80386SX16.

    If needed (to get rid of an unneeded copy of the old version, asked
    for in ROLLBALL.DOC), I'm able to give it a try with a 80486. If that
    works, and it works on a faster computer, we've rescued it.

    Whenever this minimal rescue effort required takes too long, we could
    perhaps forget about this classic (due to its age, not due to demand)
    game? Anyway, I hope it's an easy fix. Other than the execution speed-
    related problem, everything still seems to work!



    ---

  4. Re: REQ: RollBall update


    > the execution speed-related problem


    The author addressed this main problem, and the possible solution, in
    known bug #2 (it was written using a 24 Mhz CPU without cache ;-)):


    Known Bugs:
    The first time you select Options->Pause you will get an General Error,
    of type UNKNOWN. It can be ignored (retry does the same) without any
    problems. As I said, I check almoust any API for errors, and this error,
    returned by PM, is somewhere in an error-queue I think.

    Because, I haven't found any efficient implementation of a time bases,
    the speed of the game is proportional to the speed of the PC. To slow
    the game down, you must add a delay loop in THREAD.C. I possibly try
    to find a more practicable solution for this problem (adjusting thread
    priority or so?).

    Switching between the playing window, and other windows or the dialog
    boxes sometimes hides RollBall. In this case Options->Pause and Options->
    Unpause let you continue. The problem is, that if the playing ground
    is not selected, RollBall should stop from moving. I haven't found any
    good method, to check which window has the input focus.



    ---

  5. Re: REQ: RollBall update


    >> the execution speed-related problem


    > The author addressed this main problem, and the possible solution,
    > in known bug #2


    And in lines 251-258 of THREAD.C, in a comment. I'm not sure his 24 MHz
    computer was perhaps too slow to even add a single, simple DosSleep()?

    Anyway, maybe people also didn't know about this recueable game because
    it may have never worked on any computer faster than his 24 MHz one. I
    cannot recall the PM game itself, likely due to having skipped such CPU
    speeds in the early 90's. Oh, well; I hope it can be saved with minimal
    efforts required.



    ---

  6. Re: REQ: RollBall update

    On Mon, 28 Jul 2008 19:56:51 UTC, gamer@gam.esPAM (AI) wrote:

    >
    > >> the execution speed-related problem

    >
    > > The author addressed this main problem, and the possible solution,
    > > in known bug #2

    >
    > And in lines 251-258 of THREAD.C, in a comment. I'm not sure his 24 MHz
    > computer was perhaps too slow to even add a single, simple DosSleep()?
    >
    > Anyway, maybe people also didn't know about this recueable game because
    > it may have never worked on any computer faster than his 24 MHz one. I
    > cannot recall the PM game itself, likely due to having skipped such CPU
    > speeds in the early 90's. Oh, well; I hope it can be saved with minimal
    > efforts required.


    I know at least another program which suffers from timing issues: it's
    the great X128 v0.5 beta, and seems that the sources aren't anywhere
    on the Net :-(

    This is really sad: it was a good ZX Spectrum emulator, much stable
    and with a nearly perfect emulation, but with current machines it's
    way too fast to do anything.

    Mentore

  7. Re: REQ: RollBall update

    AI wrote:
    > > I know at least another program which suffers from timing issues

    >
    > Me too: PM123/Z! sometimes take just 9 seconds to play 10 seconds of
    > noise. But that doesn't really count. :-)
    >
    > > it's the great X128 v0.5 beta, and seems that the sources aren't
    > > anywhere on the Net :-(

    >
    > The author, Thomas that is, may be easy to trace, albeit the now about
    > 11-year old source code may be stored on his former school computer.
    > I think he recently competed in a sporting event, but if you're really
    > lucky it's the same guy as his @.com
    > (IMO the easiest first try, for one an interest in such music matches
    > the assumed age).


    Darrell Spice wasn't responsible for that one?

    In any case, if you do trace down the source but don't know how to fix
    it, give me a holler. If the code is OS/2-clean (no funky porting
    environments that I don't have set up), I'd be glad to fix it up with
    some good frame throttling code to run at normal speed.

    --
    [Reverse the parts of the e-mail address to reply.]

  8. Re: REQ: RollBall update


    >>> it's the great X128 v0.5 beta, and seems that the sources aren't
    >>> anywhere on the Net :-(


    >> The author, Thomas that is


    > Darrell Spice wasn't responsible for that one?


    Perhaps "porter" had to be used here instead of "author":

    X128 the Spectrum 48/128K Emulator by James McKay has now been
    ported to OS/2

    > In any case, if you do trace down the source but don't know how to
    > fix it, give me a holler.


    When it comes to RollBall, the full IBM C Set/2 source code is included
    in the original file at Hobbes.

    > If the code is OS/2-clean (no funky porting environments that I
    > don't have set up), I'd be glad to fix it up with some good frame
    > throttling code to run at normal speed.


    Ignoring other (known) bugs or bad practice, AFAICT the MAKEFILE needs
    to be changed/updated if you're not using the IBM C Set/2 but want to
    use a makefile. It's no puzzle, the author addresses the problem in
    THREAD.C, near line 250-260. I'm not sure a DosSleep() will do, which
    could be too slow for his 24 MHz CPU back then, but could work now.

    I have to assume, due to a lack of knowledge, the frame throttling
    part is a true no-brainer with your skills. Lots of comments in the
    source, and it seems to be at a MyFirstPMApp.EXE-level (IOW: not that
    complicated). The speed problem appears to be the only showstopper
    with modern hardware.

    But that's w.r.t. RollBall, not the ported X128-emulator.



    ---

  9. Re: REQ: RollBall update

    [A complimentary Cc of this posting was sent to
    Mentore Siesto
    ], who wrote in article :
    > On Mon, 28 Jul 2008 19:56:51 UTC, gamer@gam.esPAM (AI) wrote:
    >
    > >
    > > >> the execution speed-related problem

    > >
    > > > The author addressed this main problem, and the possible solution,
    > > > in known bug #2

    > >
    > > And in lines 251-258 of THREAD.C, in a comment. I'm not sure his 24 MHz
    > > computer was perhaps too slow to even add a single, simple DosSleep()?
    > >
    > > Anyway, maybe people also didn't know about this recueable game because
    > > it may have never worked on any computer faster than his 24 MHz one. I
    > > cannot recall the PM game itself, likely due to having skipped such CPU
    > > speeds in the early 90's. Oh, well; I hope it can be saved with minimal
    > > efforts required.

    >
    > I know at least another program which suffers from timing issues: it's
    > the great X128 v0.5 beta, and seems that the sources aren't anywhere
    > on the Net :-(
    >
    > This is really sad: it was a good ZX Spectrum emulator, much stable
    > and with a nearly perfect emulation, but with current machines it's
    > way too fast to do anything.


    Just run these programs inside a 386 emulator. IIRC, with Bochs the
    slowdown is about 20x... If you want more, just run Bochs inside
    Bochs (or, maybe, there are some options for Bochs?)

    Hope this helps,
    Ilya

  10. Re: REQ: RollBall update

    AI wrote:
    > I have to assume, due to a lack of knowledge, the frame throttling
    > part is a true no-brainer with your skills. Lots of comments in the
    > source, and it seems to be at a MyFirstPMApp.EXE-level (IOW: not that
    > complicated). The speed problem appears to be the only showstopper
    > with modern hardware.
    >
    > But that's w.r.t. RollBall, not the ported X128-emulator.


    I'm not really too interested in RollBall, but it did build out of the
    box with OpenWatcom. So I slapped a quick and dirty DosSleep(30) in
    there and it's playable now. Dunno if it's too slow, but I didn't feel
    like putting Timer0 code in there or some ghastly polling loop. I added
    a border to the main window, since the original author didn't seem to
    know about FCF_DLGBORDER, which offers a non-sizing border so it doesn't
    screw up his playable area. Also there was some weirdness with the
    pause/unpause, which caused an error box which never went away and
    grabbed the window focus. I worked around it and it seems to work fine
    now. Binary is here:

    http://mamodeo.dyndns.org/rollball.exe

    If someone can find me the X128 OS/2 source, I'll put a lot more
    industry into the frame throttling job there.

    --
    [Reverse the parts of the e-mail address to reply.]

  11. Re: REQ: RollBall update

    [A complimentary Cc of this posting was sent to
    Marty
    ], who wrote in article :
    > I'm not really too interested in RollBall, but it did build out of the
    > box with OpenWatcom. So I slapped a quick and dirty DosSleep(30) in
    > there and it's playable now. Dunno if it's too slow, but I didn't feel
    > like putting Timer0 code in there or some ghastly polling loop.


    ??? Minimal granularity of sleeping in OS/2 is variable, going from
    1ms to 8ms (reboot required to change) - at least starting IIRC with
    w3fp17. One does not need to do anything nasty to do this. - And I'm
    repeating and repeating it again and again - looks like nobody is
    listening...

    Scot said what with the later w4fpXX one does not even need to do
    DosAsyncTimer(), just the usual DosSleep() (with raised priority) is
    enough

    [I did not test this; "my" solution, with DosAsyncTimer(), is IMO
    much cleaner - since the actual blocking happens on "normal"
    priority (only the CREATION of the timer should be surrounded by
    raise/restore-priority code. See mssleep() in Perl.]

    Hope this helps,
    Ilya

  12. Re: REQ: RollBall update

    On 29 jul, 15:34, "Mentore Siesto" wrote:
    > On Mon, 28 Jul 2008 19:56:51 UTC, ga...@gam.esPAM (AI) wrote:
    >
    > > *>> the execution speed-related problem

    >
    > > *> The author addressed this main problem, and the possible solution,
    > > *> in known bug #2

    >
    > > And in lines 251-258 of THREAD.C, in a comment. I'm not sure his 24 MHz
    > > computer was perhaps too slow to even add a single, simple DosSleep()?

    >
    > > Anyway, maybe people also didn't know about this recueable game because
    > > it may have never worked on any computer faster than his 24 MHz one. I
    > > cannot recall the PM game itself, likely due to having skipped such CPU
    > > speeds in the early 90's. Oh, well; I hope it can be saved with minimal
    > > efforts required.

    >
    > I know at least another program which suffers from timing issues: it's
    > the great X128 v0.5 beta, and seems that the sources aren't anywhere
    > on the Net :-(
    >
    > This is really sad: it was a good ZX Spectrum emulator, much stable
    > and with a nearly perfect emulation, but with current machines it's
    > way too fast to do anything.
    >
    > Mentore


    mmm, I know I had the sources in my old computer, but it died of
    sudden hard disk failure. I'm going to check on my backups. I loved
    that emulator (I still have my Timex 2048 + FDD 3000 and my tapes and
    3'' disks in perfect condition)

    Leonardo Pino

  13. Re: REQ: RollBall update

    Ilya Zakharevich wrote:
    > [A complimentary Cc of this posting was sent to
    > Marty
    > ], who wrote in article :
    >
    >>I'm not really too interested in RollBall, but it did build out of the
    >>box with OpenWatcom. So I slapped a quick and dirty DosSleep(30) in
    >>there and it's playable now. Dunno if it's too slow, but I didn't feel
    >>like putting Timer0 code in there or some ghastly polling loop.

    >
    > ??? Minimal granularity of sleeping in OS/2 is variable, going from
    > 1ms to 8ms (reboot required to change) - at least starting IIRC with
    > w3fp17. One does not need to do anything nasty to do this. - And I'm
    > repeating and repeating it again and again - looks like nobody is
    > listening...


    In this particular case, the entire program is a polling loop (even when
    paused!), so without (re-)architecting it, DosSleep at normal priority
    was the only solution I was willing and able to implement in the 5
    minutes I was willing to devote.

    > Scot said what with the later w4fpXX one does not even need to do
    > DosAsyncTimer(), just the usual DosSleep() (with raised priority) is
    > enough
    >
    > [I did not test this; "my" solution, with DosAsyncTimer(), is IMO
    > much cleaner - since the actual blocking happens on "normal"
    > priority (only the CREATION of the timer should be surrounded by
    > raise/restore-priority code. See mssleep() in Perl.]


    I just didn't care enough about the app to do anything more. If you do,
    have at it.

    --
    [Reverse the parts of the e-mail address to reply.]

  14. Re: REQ: RollBall update


    >> I'm not really too interested in RollBall, but it did build out of
    >> the box with OpenWatcom. So I slapped a quick and dirty
    >> DosSleep(30) in there and it's playable now.


    Nor am I, but I'm glad it indeed turned out to be an _easy_ rescue
    operation, and there's also no need to keep broken apps stored at
    Hobbes et al. If it was hard, it was hardly worth the effort. IMO no
    true need to address the other known bugs, "it works".

    >> I didn't feel like putting Timer0 code in there or some ghastly
    >> polling loop.


    > just the usual DosSleep() (with raised priority) is enough


    That's the basic concept the original author guessed back in 1992,
    according to ROLLBALL.DOC, as quoted earlier:

    "possibly try to find a more practicable solution for this problem
    (adjusting thread priority or so?)"



    ---

  15. Re: REQ: RollBall update


    Excuse me for polluting the more important X128-thread again: :-)

    > Dunno if it's too slow


    It is, I guesstimate it needs a DosSleep(4-12'ish). Can you please
    include the adjusted source? I think I understand what's required
    to change the priority, it's an excuse to install OW, and with the
    source it actually can replace the broken copies (being a license-
    related "requirement").

    I don't know what the intended speed was, I don't have a 24 MHz CPU
    without cache to reconstruct the original speed. Hence the 4-12'ish
    instead of a measured difference. FWIW.



    ---

  16. Re: REQ: RollBall update

    [A complimentary Cc of this posting was sent to
    Marty
    ], who wrote in article :
    > In this particular case, the entire program is a polling loop (even when
    > paused!), so without (re-)architecting it, DosSleep at normal priority
    > was the only solution I was willing and able to implement in the 5
    > minutes I was willing to devote.


    The code IS there. Just extract it, and use it in ALL your projects. ;-)

    Hope this helps,
    Ilya



  17. Re: REQ: RollBall update

    [A complimentary Cc of this posting was sent to
    AI
    ], who wrote in article :
    > >> I didn't feel like putting Timer0 code in there or some ghastly
    > >> polling loop.

    >
    > > just the usual DosSleep() (with raised priority) is enough

    >
    > That's the basic concept the original author guessed back in 1992,
    > according to ROLLBALL.DOC, as quoted earlier:
    >
    > "possibly try to find a more practicable solution for this problem
    > (adjusting thread priority or so?)"


    In fact, it is exactly the opposite. In '92, DosSleep() was
    *absolutely* unusable for gaming - due to too small granularity.

    About 2002(?), Scot (?) finally made a change which made DosSleep()
    working "correct" in critical priority (not suitable for games, but
    who cares? ;-). Long before (1999?), async timers were improved to
    provide "good" granularity. (Unfortunately, it was not only never
    documented, but even "never mentioned anywhere". I found out it
    during some prolonged random musing like "what will happen if..." with
    a quite extensive test suite...)

    Hope this helps,
    Ilya

  18. Re: REQ: RollBall update

    On Thu, 31 Jul 2008 14:59:08 UTC, lpino wrote:

    > On 29 jul, 15:34, "Mentore Siesto" wrote:
    > > On Mon, 28 Jul 2008 19:56:51 UTC, ga...@gam.esPAM (AI) wrote:
    > >
    > > > >> the execution speed-related problem

    > >
    > > > > The author addressed this main problem, and the possible solution,
    > > > > in known bug #2

    > >
    > > > And in lines 251-258 of THREAD.C, in a comment. I'm not sure his 24 MHz
    > > > computer was perhaps too slow to even add a single, simple DosSleep()?

    > >
    > > > Anyway, maybe people also didn't know about this recueable game because
    > > > it may have never worked on any computer faster than his 24 MHz one. I
    > > > cannot recall the PM game itself, likely due to having skipped such CPU
    > > > speeds in the early 90's. Oh, well; I hope it can be saved with minimal
    > > > efforts required.

    > >
    > > I know at least another program which suffers from timing issues: it's
    > > the great X128 v0.5 beta, and seems that the sources aren't anywhere
    > > on the Net :-(
    > >
    > > This is really sad: it was a good ZX Spectrum emulator, much stable
    > > and with a nearly perfect emulation, but with current machines it's
    > > way too fast to do anything.
    > >
    > > Mentore

    >
    > mmm, I know I had the sources in my old computer, but it died of
    > sudden hard disk failure. I'm going to check on my backups. I loved
    > that emulator (I still have my Timex 2048 + FDD 3000 and my tapes and
    > 3'' disks in perfect condition)
    >
    > Leonardo Pino


    If you find it, please drop me a line. I'm trying to port FUSE, but am
    stuck somewhere. Same happens to Dave Yeo, so it seems to be a complex
    issue.

    Mentore

  19. Re: REQ: RollBall update, and Vice/2


    >>> I'm not really too interested in RollBall, but it did build out of
    >>> the box with OpenWatcom. So I slapped a quick and dirty
    >>> DosSleep(30) in there and it's playable now.


    Repeated request: care to publish the repaired source too?

    Emulators needing a fix: add Vice/2 to that list. Basicly it always
    crashes eCS 1.2 here, with several different hardware setups and with
    different drivers. It seems to be Dive()-related.



    ---

  20. Re: REQ: RollBall update, and Vice/2

    On 5 ago, 15:28, ga...@gam.esPAM (AI) wrote:
    > *>>> I'm not really too interested in RollBall, but it did build out of
    > *>>> the box with OpenWatcom. *So I slapped a quick and dirty
    > *>>> DosSleep(30) in there and it's playable now.
    >
    > Repeated request: care to publish the repaired source too?
    >
    > Emulators needing a fix: add Vice/2 to that list. Basicly it always
    > crashes eCS 1.2 here, with several different hardware setups and with
    > different drivers. It seems to be Dive()-related.
    >
    > ---


    SNAP + DIVE

    Can anyone using Panorama driver confirm if VICE/2 works?

    Thanks

+ Reply to Thread
Page 1 of 2 1 2 LastLast