gauntman

I suspect that some of the techniques discussed back in May with bitmapped soft-sprites can also be applied here. I don't know how necessary they would be if you only have 4 softsprites on screen though. The basic idea boiled down to: lda (chardata_stripe1),y and #160 ; spritemask byte 0 ora #160 ; sprite data byte 0 sta (chardata_stripe1),y lda (chardata_stripe2),y and #3 ; spritemask byte 16 ora #2 ; sprite data byte 16 sta (chardata_stripe2),y lda (chardata_stripe3),y and #160 ; spritemask byte 32 ora #160 ; sprite data byte 32 sta (chardata_stripe3),y iny lda (chardata_stripe1),y and #168 ; spritemask byte 1 ora #168 ; sprite data byte 1 sta (chardata_stripe1),y . . . Of course, you can optimize each of the shifted sprites when they fall on even character borders (when any horiz pos x&4=0, it will only be 2 strips wide, not 3); Depending on the how you are using the code, you may even be able to use x indexing instead of zero,y. Certainly, this will work for the player character that will always be the same shape in the same character range: lda playersprite_stripe1,x and #160 ora #160 sta playersprite_stripe1,x . . . inx . . . which could save a number of cycles. This might be able to work with the monsters, as long as there are no more than 3 on screen: ldx #0 ; base offset for enemy 0 jsr drawsprite ldx #72; base offset for enemy 1 jsr drawsprite drawsprite: lda enemy0_stripe1,x and #160 ora #160 sta enemy0_stripe1,x . . . Of course, unrolling a sprite will take something like 4-5k per unique shape (I think I was calculating for 12 bytes tall, not 16) which may be too much memory. Also, filling in the playerdata from the background is expensive, and not accounted for here. I suppose you could unroll the player only, since it will always be displayed, and use the slower, but significantly more memory efficient method for the monsters. I was hoping to use this method for driving ~10 character sprites during an NTSC VBI, but I don't think it will fit in the time slice (I wasn't planning on masking, only on ora'ing in the data). I may need to try writing up a routine for timing.

One more item is missing, which may or may not be what you are calling background restore: The sprite needs to overlay the background/other sprites. Somewhere I have a routine that did this, but I cannot find it on my machine at the moment. The current version of Beyond Evil may not have to worry about overlaying a background (since you can simply draw on the black screen), but sprite/sprite overlap is probably required... even if you don't allow sprites to actually overlap! For example (assuming 8x12 sprites): Sprite 1 might be at pixel position (0,0) and Sprite 2 might be at pixel position (5,14). The sprites themselves don't overlap, but the character cells do. This could be even worse if 3 sprites share the same cell. A few possibilities: 1) Ignore the overlapping - this will cause the sprites to flicker when the get close. 2) Do the overlap correctly, which will require extra processing 3) It might be possible to avoid this case by restricting actual movement to pure horizontal (x4 at a time) and pure vertical movement (x8 at a time). This way, the sprites still move smoothly, but are less likely to overlap at a cell level. To handle case 2, you will need a loop that looks something like: loop lda spriteData,y and maskData,x eor bgData,x sta dest,x inx dey bpl loop Then between each character, update the pointers to bgData. If sprites never actually overlap each other or the background, then the mask step could be skipped.

Actually, that looks pretty much like PMG. Remember, that when all 4 players + the 4 missiles are set to wide, 1 pixel in the PMG will cover 1 Antic 2 character. So, with all 4+1 players, you can cover the entire screen. If I wanted to duplicate something like the picture above, I would use P0+P1 for the first light blue column, then use a regular DLI to handle the color changes on the right hand column.

I am pretty sure that Menace was Antic 4, not Antic E.

Hi emkay, Could you please rephrase the last post? I had difficulty following the technique you were describing here... Are you running in Antic 4 (or raster mode $e)? or in Antic 2 (or raster mode $f)? It sounds like you are suggesting using maximum wide players under an inverted character/raster mask. If this is what you are doing, won't only players 2 and 3 be available at this level (since players 0 and 1 will overlay in prior 0 mode)? Maybe you could post the G2F file (if that is what you have used) to make things more clear. Thanks!

Thanks I should have read more of Mapping the Atari... So if I set my DLIST with say 32 Gr.8 (ANTIC F) lines at the top of the screen with Gr.0 with the other 160 scanlines... How would I go about making 16 of those say Gr.9 and leave the rest Gr.8? To have both modes on the screen at the same time, you will need to use a DLI. In the above example, you would need to have one display list interrupt set the appropriate bit of the hardware PRIOR register. This changes from graphics 8 -> graphics 9. Then, you will need to have another DLI turn off the GTIA bits so you properly display the Gr. 0 lines. Otherwise, the GTIA mode will continue in the character mode. This is a great way to build scrolling GTIA backgrounds, but as far as I know, character GTIA modes are rarely used. Attached is a quick example of the DLIST and DLI needed for the example you gave above. The example is for ATasm, but should work for any MAC/65 compatible assembler. dli_demo.zip

Due to University funding issues, both ATasm and EnvisionPC have moved to new homes: ATasm is now located at http://atari.miribilist.com/atasm and EnvisionPC is located at http://atari.miribilist.com/envision

D2 had several different map generators (I think I mentioned this earlier in this thread somewhere); Caverns tended to be more hallway like - dungeons tend to be more room heavy. Look at the crypts near the end of the first act of D2 for examples of room-heavy dungeons. BTW - if your machine can handle it, you should go get TitanQuest; Although there is not a random map generator, this may be the game to unseat Diablo II as king of action RPGs... Item prefixes/suffixes for bonus dmg is a good idea. "Phat Loot" is one of the major draws of D2...

To get back to a diablo-clone... I notice many games tend to have the stairs going up embedded into the walls - Diablo 1 did this and 2 has this on some tilesets. Dungeon Master on the ST did this as well (admittedly, this was a first person view).

I was playing with some algorithms on paper the other night. If you intend to use MWP as a display technique (almost a requirement if you want to scroll and have a chance at a 5200 port) - then it must be possible to draw vertical and horizontal stripes in screen space. Drawing a vertical stripe requires walking a 2D map from the NE corner to the SW corner ('/'); Drawing a horizontal stripe requires walking the map from the NW corner to the SE corner ('\'); I was considering a drawing routine based on the cavern like maps (no walls) earlier in the thread - I will be travelling this weekend, but I might have time to write this up next week.

So, for "research purposes only" I installed and played Diablo II LOD last night. (I had finally excised this from my machine, after it ate hundreds of hours over the years). A few observations after playing solid for 4 hours and finishing Act 1: 1) Randomized levels are important - having fixed levels (like Dungeon Siege 1&2, Titan Quest, just about every MMO, etc.), drastically reduces the replayability. It can make for excellent eye-candy, but ask anyone who has played Dungeons and Dragons Online how much fun it is to rerun the same dungeon 15x. In any case, we don't want to have to store all that content if it can be avoided. It is worth considering using different map generation techniques for different levels (see map comments below). See also comments on passage-heavy maps vs room-heavy. 2) A balanced and interesting drop system is a must! The drop system can make or break the game. Interestingly, I enjoyed Diablo II when it first came out, but it didn't really capture me until the expansion pack. Dungeon Siege and (even Sacred to some extent) were crippled by fairly lame drops. Fate seems to have the opposite problem -- too much uberloot cripples the game. 3) Lots of monsters attacking at once - I mean lots. I had forgotten how big the fights were - modern 3D games seem to loose this aspect. For a comparison, think of the difference between Doom and Quake. The number of monsters is approaching Robotron intensity. I don't know if that many monsters can be thrown at the player on the A8 on an isometric map Also of note, the number of different monster types in a single area (or dungeon level) is fairly constrained in Diablo - only 2 or 3 types per area. The notion of mini-bosses and minions is also worth considering for retention. (Perhaps the minions are character based only, the mini-bosses can use 1 or 2 players for extra color or effects). Of lesser importance: 4) A skill tree for customizing your character - this may not be as important in a single player game (see Fate and Dungeon Siege for examples of a generic character; Gauntlet and Sacred for examples of class-based characters). Either class based or generic, quick advancement over many levels is more fun then slower advancement over a few. Getting special powers as you progress is nice, but can be handled via equipment or spells in addition to class based skills. (See GuildWars for another very interesting way of doing this) 5) Showing equipment on your character - this may not be as important to show at the same level as modern games -- however, some basic color changes or primary weapon sets might be nice. Alternatively, if there are epic weapon drops (special 1-of-a-kind weapons) - perhaps only these have a visual impact. A few thoughts on maps: When I was working on my dungeon game long ago, I implemented the maze + room system as described above. (I prototyped in C, and saved the .bin out - later this was to be ported to assembly); I discovered that while skinny passages are nice for Rogue and Adom, they are a pain and not all that fun in action RPGs. (Perhaps this is due to having to line up exactly to go down a hall when pixel level movement is possible, instead of moving in character or tile based steps). Looking at the dungeon-like levels in Diablo (the Crypt, Mausoleuam, Dark Tower, Jail, and Cloister levels) most of the maps are simply connected rooms - passages are very rare. In this sense, the maps look more like Gateway to Apshai (the cartridge, not the original Temple of Apshai) then Adom or other rogue-likes. I suspect that this level generation may be easier and more fun to play. The second observation is that changing map generators as the player descends is probably a good idea. Interspersing cave levels as described early on in the thread with more traditional dungeon levels (some room dominate, some passage dominate) makes for a tastier mix.

Yes. Fate captures the essence of the Diablo-Roguelike game without complication. And it is a lot of fun to play. Another iso-game is Avernum. Of particular interest is the way they handle foreground walls. This is one of the methods I was trying to explain above, but a picture is worth 1,000 words. Notice how the front walls are "chopped" - this should be very doable on the Atari. See it here.

Regarding walls: Diablo 2 had an entire section (The Great Library, or something like that) that had no walls - and it worked fairly well. However, it had a very different feel compared to the rest of the game. See a screenshot here. (Not a very good example of the level, but the only I could find). One of the biggest problems with visible walls will be handling the foreground. Either the walls need to be short enough so the top part of the player can be seen - or the front walls will need to disappear when the player is in that room. (Dithering the wall will probably look too ugly, and partial opacity of the wll is out of the question. I suppose it might be possible to shadow the player and monster shapes in some way though). Another option is to handle the display like some of the Zelda games. Each room is centered on the screen with exits at the side. The only time the screen scrolls is when a doorway is entered. This way, you can always properly draw a room with the backwalls showing and the front missing (except for doors, perhaps). Unfortunately, scrolling like this would probably interrupt the pace of the game if you are being chased by monsters through rooms and corridors. BTW - pseudografx, the latest screen mock-ups look great! I really like the iso view. *edited* to add another game name: A recent Diablo-like is Fate. This is true 3d, but has a fixed camera angle (like Titan Quest). A simple, straight-up dungeon romp.

One idea for an isometric look is something like the following: This style means there are no walls to block the sprites, so masking/clipping against walls is no longer an issue. The "ragged edges" would be filled in with regular flooring as the player approached. When the player got close enough to the edge of the screen, the whole screen would scroll, placing the player back in the center. The main player could be built from players 2-3. Monsters would be character-based soft-sprites. This leaves the other 2 players free for doors and archways on the foreground planes (probably the same color as a character so back-plane doors and arches can be displayed with characters). With the proper priority, the foreground doors and arches would overlap the player sprite and the monsters and the players and monsters overlap the background - free hardware-based obscuring. Unfortunately, this does limit the PM colors that can be used for overlaying monsters.

Yes, a seperate attribute list is used. The tilemap only stores the fact that an object exists at this location. This requires a seperate look-up on decompression.

Yes, you can set the HSCROLL and VSCROLL registers in the DLI, so independent regions can be made to scroll pretty easily. Just remember that the scrolling bands cannot intersect. So for instance diving invaders or bullets will need to be PMs

I may be able to help out a bit on the coding side of things -- although life is ridiculously busy at the moment. I did some initial design work on an action-Roguelike for the Atari (and keeping an eye on the 5200 so RAM was tight) back in 2004, but did not get much further then some initial mock-ups. Here are some notes I had on data-design, I am pulling most of this from memory, plus some scribbled diagrams on 3x5s but I will try to recreate the basic idea: Each map level is made up of 128x128 tiles (6 screens wide by 6 screens tall). Dungeons are stored as tiles with each nybble representing a 1x2 block. Values: 0 1 2 3 empty wall empty floor empty empty wall floor 4 5 6 7 wall floor wall floor* floor wall floor* wall 8 9 A B So, for instance the byte $B1 would for the upper-left-hand corner of a room floor floor* floor* wall ## floor* floor floor* wall #. This leaves 4 more tiles left over for something else (water, perhaps). The asterisk indicates that an object/door/inactive monster is on the tile, and the object list is held separately in memory. This gives a 4x reduction map storage so a 128x128 map will take 4k instead of 16k. The screen itself is rendered using the MWP scrolling technique. When uncompressing the tiles, if an object tile is flagged, the X,Y position is added to the activated object list. An additional 512 bytes is used as a 4-item deep radix list based on object position (so 4 items can exist on a horizontal line before bumping to next entry in memory) for the actived object search. Actual objects are stored elsewhere in memory and contain position, type/shape, etc. Objects left on the map would decay over time and eventually disappear. This approach squeezes tile-map (4096 bytes)+ MWP screen (400 bytes) + object look-up table (512 bytes) into under 5K. (Note: Originally, I was designing this in ANTIC mode 6 (20x20), but ANITC mode 4 would work just as well, although it doubles the MWP screen real-estate to 800 bytes and just over 5K.) The main problem with this approach is that decompressing on-the-fly for MWP may be too expensive to allow very many active soft-sprites. I may try to put togther some code and see if this design is plausible in the real world...

Envision 0.8 for Mac is now available. It is downloadable via the website. Enjoy!

I hope to have an OS X version available this weekend.

Well, I am out of town for the next few days so I figured, "what better time to do a product release?" EnvisionPC 0.8 has finally been completed and is ready for download at the usual place. Although it is hard to see, the screenshot really has changed! (primarily the command menu has been updated) New features since 0.8-preview: 1) Map re-tiling 2) Various bug fixes 3) Documentation updates New features since 0.7: 1) Tile-based map editing mode(!) 2) Larger maps 3) Various bug fixes New features since 0.5: 1) Converted to SDL The delay in this release was due to finishing up an exciting new feature: map re-tiling. This lets you edit the map normally in character mode, then when you ready: converting it to a custom-sized tile map. This command is toggleable, so you can edit in character mode, convert to tiles - edit in tile mode, and convert back to characters. This makes it much easier to test a tile-based system without committing yourself! Pull down the program and let me know what you think. If anyone has some better screenshots of EnvisionPC in use that I can use on the webpage let me know. The current shots are the result of about 2-3 minutes of quick editing. A screenshot demonstrating tile-based editing would also be nice.

I am looking at wrapping up the 0.8 release of Envision this weekend and getting it out the door. So -- Has anyone run into any crippling bugs or have suggestions for more sane keyboard commands?

This is the preview of EnvisionPC 0.8. This adds some new major features as well as fixes a few bugs that snuck into the last release. The official release will probably be this weekend, once I have had time to update the documentation and finish one or two additional items. In leiu of documentation, here is a walkthrough of how to use the new tile-based map mode (note, the normal character map editing still works fine, don't panic!): 1) Start-up EnvisionPC, and click on the title screen to enter Edit Mode 2) From Edit Mode, press 'm' to enter Map Mode 3) From Map Mode, press 'b' to enter Tile Mode ('B' for blocks, I need to fix the hot-keys!) 4) In Tile Mode, press 'z' to define the tile size. If the tile size is ever larger than 1x1, then the map mode will use tiles instead of characters. In this case, enter a width of 2 and a height of 2. 5) In Tile Mode, use the same drawing methods as in map mode - notice however that now you are actually defining the tiles. The upper left corner is tile 0. The tiles are laid out in a 16x16 grid. 6) Define tile 1 as something more interesting then blank space. 7) press 'b' again to toggle block mode. You are now back in Map Mode, but notice a few things are different. The status bar now displays the drawing tile instead of the drawing character. Also, your cursor is now the size of the tile, rather then the size of each individual character Draw in Map Mode using the current draw tile. That should be enough to get you started. Let me know if you have any problems so I can fix them for the next official release. envision_0.8_preview.zip

Progressing. I will post a preview of the next version tonight. This is not the full release, as there are a few features still missing. However, this version does include: 1) change all color registers 2) removed 512x512 map limit (now 65535x65535 is the max) 3) "Go To" command on the map screen 4) Prompt for exit dialog 5) Option to edit a map of tiles w/custom tile size (i.e. a map can use 2x2 tiles or 4x5 tiles, etc.) Still missing: 1) Documention 2) automatically Untile/Tile a map 3) a few save/load options Note that this will be a preview release in anticipation of the next real release.

If I recall properly, PF1 = 708 PF2 = 709 PF3 = 710 PF4 = 711 <- The "5th" color The missing color is the background (PF0 - 712);

A few quick comments: 1) Atarimac was kind enough to provide a MacOSX version of the now mildly inaccurately named EnvisionPC. The binary is available on the website along with the XCODE project. 2) EnvisionPC does not have tile support yet, although I think it should be possible to add. I will look at this over the weekend. 3) Changing the background color - this is easy and will be in the next release. 4) Selecting the 5th color - this can be done today, just select the inverse character when drawing in ANTIC 4/5. (When typing or selecting a character use ALT as the Atari key) 5) PM overlay preview - this is trickier, but I will think about how it might be done - as a preview in character editing if nothing else... 6) remove the 512x512 limit - also easy, this will be in the next release as well. At the time of the original release, this seemed huge! There is also a known bug in the 0.7 release with selecting a draw character (or find character). Use the keyboard to select the character until the next release. I missed a coordinate transform in the SDL port, so picking a character with the mouse will give - er, uneven results.