Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

unhuman

Members
 View Profile  See their activity

  • Content Count

    1,270

  • Joined

  • Last visited

Posts posted by unhuman

  3. Posted

    Inaccurate Invaders is up. Saved a line of code and added a lot of stuff - more colors, etc... Wonder if there should be a reward for the most characters used in a game - per line average. Some lines are hard to get out of being short IF / THEN confusion, but... I think I packed 'em pretty tight :)

  5. Posted

    Or can he give his spares to me. My title screen is... Boring.

     

    My game is done. It's exactly 30 lines + data. Not releasing yet - I have a bug.

     

    -H

     

     

    Question for the judges (or, well, Owen).\

     

    I am nearly finished with a game and I have a couple lines left over. I'd like for the game to save and load high scores to disk. Is that kosher, since it's not loading numeric or string data to get around the 30-line requirement?

  7. Posted

    Bagman needs to be made for a classic console and the 7800 is ideal for it! It was such a fun game and still is today! I spent a pile of quarters on it many years ago. Seeing as it hasn't made its way onto a classic console, why not the 7800?

     

    There has to be some trick to success in this game. I threw away tons of quarters, but never got anywhere. Still can't.

  8. Posted

    I see Simon!

     

    Hi folks,

     

    Great challenge idea ;)

     

    I'm going to toss my hat in the ring with a TI version of a "colorful" electronic memory game that was popular in the 80s. Maybe not the most original concept but I've had fun writing the code. The only concern I have is that I wrote it on the Geneve, which is a little faster than the TI. At last count I had 11 data statements and 28 lines of code... just enough room for a tweak or two :cool:

     

    Tim

  9. Posted · Edited by unhuman

    My game is getting close. Made a few sacrifices, but... Overall, I think it's gonna work out. I wonder what the average hours / line spent.

     

    Oh - and I'd like a little help. My ability to generate sounds sucks...

     

    Anyone got a "shooting missile" sound? One call sound pls :)

     

    -H

  11. Posted · Edited by unhuman

    So are you telling me that all the games I played 30 years ago could've sucked less? Also, since you talk about CALL COINC reading at the end of the frame, does that mean using it will slow down my game unless I get lucky that it runs near the end of a frame? That stinks.

     

     

    --> So why does the interrupt routine miss collisions, when it should be reading at the end of the frame?

     

    I really don't think the ISR is missing the collisions. I believe that the COINC,DELSPRITE,COINCE series is occurring before the ISR is activated again IE XB is outrunning the VDP interrupt. This would explain the fall out every time with no delay, sometimes with 1 delay and never with 2 delays. I would be interesting to know if the sprite routines are in the ROM or GROM. I suspect the ROM due to the speed. Any ideas?

     

    That's my problem, that doesn't explain it. That theory has potential for your case, but makes no sense in mine.

     

    Look at the example program that I'm working with, not your example. My sprites are not moving. They are always touching. So the COINC should never return 'no coincidence'. But it does, and so does the CALL PEEK. If the ISR is the only thing writing that memory location, as my debugger tests suggest, then yes, the ISR /is/ missing coincidences. This is observation and not supposition.

     

    Let's start with the simpler of the two cases.

     

    I should have paid more attention to what you wrote ;-/...

     

    I tested your code on my console and saw the results first hand. Your code on my console resulted in about 50 percent missed hits. That seems disheartening for XB programming. Now the strange gets stranger......

     

    I got sick of trying to keep track of the scrolling ones and zeros so I changed the print format to..STR$(ABS©); in order to just see the 1's and 0's. This resulted in a reduction of misses to about 1.4 percent. On a whim I turned off all sprite motion with CALL LOAD(-31806,64) and got zero missed COINC's (out of 1000 tries.) This is beyond my scope so I will defer to your expertness in things of this nature but I would suspect that something other than the ISR is reading the VDP ROR or the scratch pad location is getting changed by some lurking XB/console bug. Perhaps a call to the TI software engineers is in order ;-)

  12. Posted

    I do all my dev in a text editor and paste the code into classic99... my code looks like this

     

     

    REM my code initializes better than your code

    10 initialize

    REM my code plays better than yours

    20 run game

    REM my graphics look better than yours

    40 DATA my, graphics, rock

     

    By putting comments as REM lines they can be pasted, but do not wind up as code. Sneaky, eh?

     

    The ! does not work in my environment for some reason, it always throws a syntax error. And none of my lines are short enough to add comments to the end. :)

     

    It's fine, I'll keep them in until I submit it and then rip them out of the public version. :thumbsup:

  13. Posted

    Why do you recommend gosubs? That is extra stack manipulation and steals clock cycles. Right now, I've got my entire game loop with no externalized operations. Just a tight loop. What would be a really good thing to have at some point is documentation on how long each operation takes... But, I'm sure nobody has time for that.

     

    I've got a few more things to put into my game loop - I'm going for all the marbles in my game, else I'll fall back to my "less good" strategy. I'm pretty amazed at how many moving objects (w/o sprites) one can have :)

     

    -H

     

    Once you've done a few XB games, it becomes pretty apparent which functions work well together (i.e. Which ones don't "fight" each other for supremacy) and also the best way to manage your gameloop to keep it as tight and small as possible, branching out with GOSUBS. The cool part is building your loop to facilitate ONLY the most absolutely necessary "checks" and then realizing your entire loop takes up only 3 lines--- the rest is setup and GOSUBs. To spill the beans, I've started a 30 liner myself--- it won't count towards the contest, but I caught this bug too--- and I gotta have one on the compilation disk. :). Anyone who contributes a game will receive a free compilation disk, in 5.25 or in 3.5" format---courtesy of Opry99er. When the contest is over, just send me your address and I'll send one your way!

  16. Posted

    I'm actually pretty surprised the amount of work I'm doing and how responsive the system has been. Of course, I'm probably fully loaded and as soon as I add more game elements, I'm probably screwed.

     

    --> So why does the interrupt routine miss collisions, when it should be reading at the end of the frame?

     

    I really don't think the ISR is missing the collisions. I believe that the COINC,DELSPRITE,COINCE series is occurring before the ISR is activated again IE XB is outrunning the VDP interrupt. This would explain the fall out every time with no delay, sometimes with 1 delay and never with 2 delays. I would be interesting to know if the sprite routines are in the ROM or GROM. I suspect the ROM due to the speed. Any ideas?

     

    Perhaps XB is faster than I previously thought.... :-)

  20. Posted

    Damn zomb is awesome... One minor issue is that sometimes zombies appear right on top of your head, so you get no chance to live. Should be a minimum distance safety zone :)

     

    The bar is set high!

     

    Ok - now I'm gonna feel stupid. I've been using Classic 99 to run, since it supports cut and paste so nicely, etc... but... I cannot get it to use any of the files on disk... Copied the ZOMBXB to the DSK1 dir and doesn't work "OLD DSK1.ZOMBXB" - error 7. Disk menu is disabled... :(

     

    I'm not so dumb. I had to pilfer the classic99.ini file from Tursi's site forum to fix this... No disk driver.

  21. Posted · Edited by unhuman

    Ok - now I'm gonna feel stupid. I've been using Classic 99 to run, since it supports cut and paste so nicely, etc... but... I cannot get it to use any of the files on disk... Copied the ZOMBXB to the DSK1 dir and doesn't work "OLD DSK1.ZOMBXB" - error 7. Disk menu is disabled... :(

     

    I'm not so dumb. I had to pilfer the classic99.ini file from Tursi's site forum to fix this... No disk driver.

  22. Posted · Edited by unhuman

    My program uses auto-motion right now... I should try seeing if locate would work better for me... It certainly would give me the accuracy I'm looking for.... So long as I can keep the time in my loop pretty normalized... It'll be okay. But... That might be hard to do.

     

    Well, I am currently writing a MAP screen for my RPG, and I move the character around the screen using ESDX. Note that this character is a SPRITE. I COULD use GCHAR too keep my SPRITE from entering the town... Basically, this is just an example of howhow to move the SPRITE by increments of 8 and having another variable that determines actual screen position. For instance::

     

    100 Y=40 :: X=40

    200 YC=Y/8 :: XC=X/8

     

    **Sprite sits at Y,X (YC, XC) ---> actual screen position of 5,5

     

    When moving this SPRITE, I only allow it to move by increments of 8, so it always occupies a "real" character position. For a game where you are limiting the movement of your play piece to certain "character," using a CALL JOYST function in conjunction with a GCHAR statement is fast and efficient. =)

     

    PSEUDO CODE::

    IF PLAYER MOVES RIGHT, CALL GCHAR(YC,XC+1,A) :: IF A=32, then you can't go there

     

    Check out Tursi's program... I haven't studied it, but I'm pretty sure he uses the GCHAR and JOYST in conjunction. With a SPRITE, you can move it by using CALL LOCATE, as I do in my MAP if you're avoiding auto-motion. In the MAP program, it's simply a half-drawn map with an X that you move around using ESDX, instead of JOYST.... But the CALL LOCATE function is just a way to jump your SPRITE from one real screen position to another. I do not use CALL GCHAR in this program, rather I calculate the YPOS and XPOS upon player input for direction, and if they're outside of my boundary, I don't allow it to move... the boundaries are the screen barriers on right and left, the bottom of the screen, and the mountains in the north. I guess I'll attach the map here... It's nothing but a tester for a few things, but you can see how it works pretty easily. =) Hope this helps

  24. Posted

    Right - well that's where you sort of lose track. Porting to another emulator (system) is probably just as hard if not harder - basically you're asking him to convert it to an old platform, which wouldn't have the feature sets he uses in the game.

     

    That's why I mentioned SDL - if you look carefully at the emulators supported on the Wii, a vast majority of them leverage SDL. Someone wrote the original emulator with SDL, and then porting to other systems is far easier than writing to the base platform. It's sort of a common functionality layer that manages graphics and sounds.

     

    -H

     

    Games written in SDL are "easy" to port. Other stuff, probably not so much.

     

    That's just too damn cool!

     

    I'm almost afraid to ask if that can be ported to some emulator, or as a stand alone so that I can play it on my 42" HDTV with Wii Homebrew Channel.

     

    That arcade action is really slick!

     

    Well Done!

     

    It wouldn't have to be ported specifically to the Wii. Just port it to an exisiting PC emulator (Atari 2600/7800/NES/Coleco, etc - oddly, there's no Intellivison Wii emulator yet that I'm aware of.) Wii homebrewers have already converted the emulators, so as long as your rom image works on a PC emulator, it' work on the Wii.

     

    Or how 'bout configuring optional joystick controls for the PC?

     

    But I'm no programmer, so I can't imagine the amount of work this might require.

     

    Anyway, whatever you decide, keep up the good work!!

  25. Posted

    Games written in SDL are "easy" to port. Other stuff, probably not so much.

     

    That's just too damn cool!

     

    I'm almost afraid to ask if that can be ported to some emulator, or as a stand alone so that I can play it on my 42" HDTV with Wii Homebrew Channel.

     

    That arcade action is really slick!

     

    Well Done!

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...