Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by jacobus

  1. Hi Stefan! I think you are playing an older version - before I had visible weapons. The new version correctly shows the weapon on a PAL machine (at least under emulation) and the Zombies do appear red! Thank you very much for your beta test offer, I will take you up on that!
  2. The red characters are zombies, the others are uninfected. You can kill both, but you'll get penalized for killing (murdering) the uninfected. thank you! Because in real life you can't either! Adds a little challenge to the aiming process. In the newest version, the stronger Zombies can't be killed in one shot and when you hit them with a projectile weapon they are knocked back a bit. I've revamped the scoring system - the old system was the failure not you!
  3. Thanks to everyone who made constructive comments! The feedback is much appreciated! I'll respond in the next message. The game is progressing now that I have some time. I've done up a couple of demo videos (still a few cosmetic issues), and I'll send copies to interested people soon. Level 1 https://youtu.be/mw3e9fvHM_M Level 5 https://youtu.be/gNiwV2yBbug The sound effects are still awful because I am just lousy when it comes to programming sound effects. If anyone would like to help here, please let me know!
  4. It was too good to be true I sincerely hope so! For the record, one of my first experiences here at AtariAge was a nasty email exchange with guntar over a simple difference of opinion - guntar quickly moved to insults and putdowns to try to make his case and I have been trying to ignore him ever since. I write games for the Atari because I enjoy writing games for the Atari. I have no expectations of becoming rich (hell, I barely broke even on the DH sales), I do it because I have fun doing it. Because of that, I have absolutely no tolerance for a-holes who try to get in the way of my enjoyment. At the same time I have a tremendous amount of respect and gratitude for the people who purchased (and some of them purchased multiple copies!) Dungeon Hunt when it was on sale. I really don't want to risk cheapening their investment by either putting it in the public domain or diluting the market by adding more copies (no quantitative easing here!) Again, thank you to everyone who purchased a copy, and since I can't say it too often and huge thank you to my beta testers who really helped make the game a success!
  5. For the commercial versions, only the media and package are different. The ABBUC demo version includes only the first four levels.
  6. I've been ignoring guntar up to now as that it appears he has been angling for a free copy. All this talk of magazine reviews and coverage that he goes on about - always very vague and non-specific of course - seems to be just a feeble way of trying to impress me and make me hand him free stuff. He carefully chose not to purchase one of the last two disk copies when offered, but continues to agitate for a free one. And in typical guntar fashion, when he doesn't get his way he gets all pissy and whiny.
  7. Sorry about the delay in getting back to everyone here! OK, the word on Dungeon Hunt is that distribution is pretty much finished. I have two disk versions, one cartridge version, and absolutely no digital versions remaining in inventory. I am happy to offer the remaining two disk versions on a first-come first-serve basis ($30 + shipping) - please PM me if interested. Not sure what I will do with the cartridge version, I may offer it on eBay (sorry, I know that's kind of a-holeish of me, but I'm really curious what the last copy would go for...). Out of fairness to the people who paid good money for the product when it was offered (thank you all very much!) I am not going to release the game into PD any time soon - if ever. I am however considering a very limited release of DH as well as about a dozen other games and utilities that I have written over the years. They would be packaged in a MaxFlash cartridge, and (likely) a fancy box. No dates on this, I have to finish a couple of games and write one more to fill it. (teaser below :-)
  8. Attached is a new game, still rather rough but I'm interested in any feedback. I may have gone a little overboard on the dark humour here, so if you're easily offended, please run back to mommy, please be warned! ZombieAttack!.xex Zombie Attack Manual.pdf P.S. Imp is still being worked on, I'm finding the level design to be a major pita, but hopefully we'll see something soon.
  9. I played around with the Altirra .altstate format and figured out a solution. If anyone is interested, I've included some VBS scripting code to convert the .Altstate file to an XEX. Command line batch file (input file, output file) cscript MakeXEX.vbs zatest.altstate zatest.xex VB Script file (MakeXEX.vbs) Dim fso Dim fH Dim InFileName Dim OutFileName Dim StrData Dim Header Dim BinaryLoadFile Dim StartLoadAddr Dim EndLoadAddr Dim RunAddr 'set parameters BinaryLoadFile = Chr(255) & Chr(255) LoadAddrStart = Chr(0) & Chr(0) LoadAddrEnd = Chr(191) & Chr(253) RunAddress = Chr(0) & Chr(80) 'create file object Set fso = CreateObject("Scripting.FileSystemObject") 'get command line InFileName = Wscript.Arguments(0) OutFileName = Wscript.Arguments(1) 'open source file fSize = fso.GetFile(InFileName).Size Set fH = fso.OpenTextFile(InFileName) StrData = fH.Read(fSize) fH.Close 'strip Alirra 2.6 header StrData=Mid(StrData,260,65796) 'trim to 48K StrData = Mid(strData,1,49150) 'add new header Header = BinaryLoadFile & LoadAddrStart & LoadAddrEnd StrData = Header & StrData 'add footer StrData = StrData & RunAddress 'save dest file Set fH = fso.CreateTextFile(outFileName, True) ' Write fH.Write StrData fH.Close Just make changes to the 'Set Parameters" section to adapt to your requirements. (Currently set to load all of RAM from $0000 to $BFFD and then execute at $5000) The script also assumes .Altstate format 2.6 (not sure if this changes very often)
  10. I'm trying to accomplish to a work-around for some of Quick's limitations - namely the 20K program code limit. With the standard compiler, I have two options for a program, a) include all secondary data (graphic, sound, DL, etc) within the program space and create a standalone executable, or b) off-load everything but program code and load the secondary data into memory at run time. The problem with a) is it severely limits the amount of code in a program, the problem with b) is that I need to create and distribute an entire disk with the main executable and all of the secondary files. Ideally I'd like to be able to run the application, have it load up memory with the secondary data and then snapshot the contents of RAM into an executable that when loaded would populate memory with both the code and the secondary data. Not sure if such a utility exists within the Atari, or I should be looking at a tool that could perhaps modify an Altirra save state file. Any ideas would be greatly appreciated!
  11. Update! I’ve attached a playable demo of Imp! It works, but there are lots of things still left to do (including all sound), however, there should be enough here for you to get a feel for it. The first level is fairly complete; you’ll need to navigate the playfield, unlock doors, collect stuff, fight off a bunch of monsters and locate the exit. Good news, the monsters are all pathetically weak and you can’t get killed! (how great is that?!) If you find the exit, you should start again in level 2 (which looks almost identical to level 1). I’ve included three levels in the game, they are all more or less the same, but the game will likely crash after level 3. I have not tested using real hardware, but I don’t anticipate any compatibility issues. Control via Mouse 2 or Joystick 1 – the spacebar switches between current weapons and the bow. One last thing – I find few things more irritating than seeing large numbers of people downloading one of my programs, and very few people commenting on it. So please, if you’re going to take the time to download, please post a comment! I do this just for the attention, and if I don’t get enough, chances are the game won’t get finished! :-) Imp.atr
  12. That would be awesome! Thanks very much! Still a long way to go! I've had a couple of people mention this, so I'll give it some thought. One argument for it, is that the dashboard requires a mouse to navigate efficiently - and since you are already using the mouse there, using the mouse for the game seemed logical. Thank you!
  13. I have new game in the works – this time a Diablo clone! OK, calling it a ‘clone’ is a bit of a stretch… I am writing a game that a very distant cousin to Diablo, smaller, plainer and simpler. To acknowledge its obvious lack of stature, my working name for the project is “Imp”. I actually started Imp way back in 2014, dropped it in favour of Dungeon Hunt and recently picked it up again. In hindsight I’m glad I waited - from a technical point of view this game is a lot more challenging than DM and I’ve managed to learn quite a bit more about the language (QUICK) in the intervening year or so. Imp features a large scrolling playfield – 128 x 48, multiple levels, melee and ranged weapons, multiple NPCs and an interactive equipping/outfitting section. Memory optimization is key with the Quick environment, and my executable code is currently around 12K with most of the main features roughed in. I’ll have the luxury of using the remaining memory for polish and extras. (Quick limits the program to 20K of main code) The plan is to have about 10 levels, each populated with scenery, objects, NPCs etc. Using the magic of LPE compression I should be able to fit them along with the game and all supporting data onto a 90K floppy. And of course, all of this will run on a stock 800 with 48K. Control is via either a mouse or joystick with a few commands accessed via the keyboard – the mouse is the preferred method. Please note: The colours and many of the graphics are still very preliminary! https://youtu.be/90OmMoxDnT8 https://youtu.be/f7WzJFm9HcA Fog of War This was an interesting feature to implement, I played around with several different techniques but came back to the simplest one – I have two copies of the map. The first one called the Player Side is on the left and initially entirely filled with a single character (fog). The second, called the System Side contains all of the map, NPC and POI details. As the player moves their character over the Player side, I draw a (before rounding) a 12 by 7 character ‘window’ of playfield graphics from the System side to the Player side at the current player position. The player is prohibited from ever visiting the system side and the illusion that the fog is rolled back to reveal the playfield is maintained. Playfield Graphics The perspective graphics are a pain to design but have great impact. Just to keep things interesting I’ve allowed for an entirely new character set to be defined and used for each level. This will allow the terrain and NPCs to keep evolving as the game progresses. Of course it also makes for a lot more design work for the level developer(s)! Dashboard No RPG game is complete until you can get killed while fooling around with weapon selections. The Imp dashboard will allow the player to select their defensive capabilities on one hand (shields etc) and their offensive weapons with the other. The exception here is the ranged weapon which forces the player to put down their shield to use. Both armour/shields and weapons are leveled and will accumulate damage as they are used. The playfield can contain specialized areas (store/smithy) where items can be bought/sold/repaired/upgraded. NPCs Aside from the active opponents in the game, you will also be able to interact with doors (locked with a set of keys), break barrels and ransack chests for treasure (redeemable at the local store). Weapons Currently the player has both melee and ranged weapons available, I’m debating about including a magical element… I plan to release this game to the community when complete (although a very small cartridge run is a possibility). In order to get to that point however, I have a lot of work – levels to design, sounds/music to create and lots of play testing to accomplish. If anyone is interested in helping with any of these tasks, please feel free to contact me.
  14. I frequently used David Young's version - if I remember correctly it had write verify turned off by default along with the full disk copy feature mentioned by Rybags. David Young Modified DOS 2.0S
  15. Great list, but I'd add: 11. a second joystick button
  16. I'm sorry to say that all of the cartridge versions have been sold. (actually I'm quite pleased, but I'm sorry to have to tell you this) I'm thinking about putting a copy I held back for myself up for auction, but I haven't decided yet.
  17. SOLD! Thanks everyone for your interest!
  18. I just posted one in the Marketplace
  19. Brand new Incognito - never installed, still in package. From the first run of boards.
  20. Great project! I was a Clipper programmer as well - amazing what could be done with that language! Dot prompt support would be awesome, but I think memory requirements would make it impossible! Many years ago I wrote a dBase III clone (including an interpreter for the language), but that was on the PC.
  21. Thanks for this Jeremy! From the very first time I played Sudoku, I had a definite itch to write a solver - thank you for saving me the trouble!
  22. Nice thing about Quick is the very rapid development time :-) OK, so now you can use the < and > keys to roll the bytes up and down (within the sector), as well as press the "S" key to double up characters in the Explorer (I'll revisit closing the the space later). Images here are from Necromancer, before and after rolling the sector with a good chunk of the character set. Both of these features only work in the Explorer. and the spacing option invoked: Program DiskExplorer v4.atrDiskExplorer Boot v4.atrDiskExplorer.XEX Docs Disk Explorer v4.pdf Source FE.TXTFE.LIB.TXT
  23. Just in time to miss MrFish's request here is version 3.0. :-) Joystick support, and now the Editor has the ability to output (via print) either the current sector or a range. This feature is really intended for emulator users to copy and paste with. I've also messed with the interface a little, START brings up the Explorer exclusively, SELECT still shows the Selector and now OPTION selects the Editor. MrFish - An option to close up the columns is certainly possible, it will cause some pain with the hot spots so it might take a few days. Just of out interest, would you prefer closing the spaces, or doubling up the current chars (ABC or AABBCC)? Thanks again for the feedback! Boot, Autorun and file versions attached, as well as current source code. Program: DiskExplorer Boot v3.atrDiskExplorer v3.atrDiskExplorer v3.XEX Manual: Disk Explorer v3.pdf Source: FE.LIB.TXTFE.TXT
  24. I suppose joystick support would not be out of the question - would you be OK with that?
  25. Andreas - good points, I will include both versions in the next release (likely last, as the only thing I want to add is the ability to output the sector(s) as CSV). I knew there must be a tool like Super-Copy, seems that most of the disk tools are boot to binary converters only. Thank you very much Xuel - much appreciated! Doc - thanks ... Just call me Thomas :-) Ryan - not surprising, only so many ways to represent disk structure using a character based system. Hmmmm, that brings up a good point ... I wonder if I should switch to a graphics mode in order to represent the disk sectors? I could use Antic $0D - four colours would give me enough to show normal, empty and directory sectors and one more colour to indicate the current file. This would also allow me to show an entire ED disk... (pretty sure I want to stay away from DD disks - the 256 byte sectors would break the Explorer and Editor screens). Then again, considering the mouse sensitivity issues, this might not be such a great idea. I'll have to play around a bit.
  • Create New...