Cybernoid Posted July 3, 2006 Share Posted July 3, 2006 5s sounds good. just installed borland c++ to get into c/c++. its more than 15 years at university where i had my c class... time to refresh. the exe file is 7k... si should i reserve 8k for the level generator? If you want to use CC65 to do the game, then you do not need to reserve 7k. There are some extra things in there that are not being used from the Atari library or will be reused by the rest of your code. Some C init stuff will take some space, too. If you use assembly and convert the dungeon45.s file, then I believe that it should only take a little over 2k for the actual level generator. Take a look at the dungen.map file in the zip file. It should show where everything is. You do not need some of the printf and other things. However, I am not sure how to not include it. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 4, 2006 Author Share Posted July 4, 2006 what would be an atari friendly formular for hitting a monster? player has same stats like in diablo1, so he has a weapon, armor and a "to hit"-value. what about the strength? Quote Link to comment Share on other sites More sharing options...
Cybernoid Posted July 4, 2006 Share Posted July 4, 2006 Hmm, have to think about doing the hit calculation.... Here is an update that shows the dungeon being generated. There seems to be a bug with the left border and top border on the Atari. I have an idea that this might have something to do with unsigned chars versus signed ints... The dungeon is shown in GR.11. The width is currently twice as wide as it needs to be... dungeon.zip Quote Link to comment Share on other sites More sharing options...
miker Posted July 4, 2006 Share Posted July 4, 2006 Well, waiting for some more. Btw. Heaven - that pizza was poisoned. Germany sits in front of TV. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 4, 2006 Author Share Posted July 4, 2006 i am little bit sad... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 4, 2006 Author Share Posted July 4, 2006 i am reading several rule books to get a working rule set for the game... (WoW, Diablo 1, Diablo 2 board game, D&D, D&D board game, etc...) there must be rule set which is simple but good enough for the action game... Cybernoid, the map looks good, now we just have to give the walls different colours the NW-SE walls and the NE-SW ones because they have different tiles... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 5, 2006 Author Share Posted July 5, 2006 i am just started to compile a Design Doc for the game as it gets more complex. forgot to mention this site: http://members.core.com/~dfrease/JGFrame.html here are the rules for Diablo 1 (not 2 which is more complicated). I am compiling the most important stuff for 1 character and try to simplify them with my A800 eyeglasses on... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 5, 2006 Author Share Posted July 5, 2006 btw... just a small interesting part: "When the game checks if you have hit there is always a 5% chance that you will miss, no matter what the final modified To Hit is. In the same way there is also always a 5% chance to hit, no matter what the final modified To Hit is. See chapter 5.1 for information about monster's chance of automatic hit (they never automatically miss). " as i am more and more familiar with dungeons & dragons and the D20 rules... you might know that a D20 is rolled... and by the D&D rules a 1 is always miss and 20 always hit... 1/20 = 5%... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 5, 2006 Author Share Posted July 5, 2006 ok. here is another turbo basic prototype: i implemented some of the diablo rules just to see if i got it right and captured the basics. just boot the disc and type RUN "D:DIABLO.TUB" you are presented with high class gfx done by the ASCII ENGINE. you can move the player sprite around "O" while the zombie ("X") tries to catch you. your stats: Strength: 30 Dexterity: 20 Vitality:25 Character Level:1 you are carring a Lether Armor (Armor Class 10) and as weapon an axe with minimum damage of 4 and maximum 12 the monster is a zombie and has an armor class of 5 and has 30 hitpoints. the zombie carries a small rusty nife with minimum damage of 2 and maximum damage of 5. when both collide both player and zombie battle. you can see the results in the corner of the screen. there is no check if player or monster bits the dust... so... these are the battle basics of Diablo... no rocket science... please have in mind that this is just a test to get a feeling for it... now image this arena fight done in 3d iso and with sprites and by pressing fire each time you want to hit the monster... 10 GRAPHICS 0 15 POKE 82,0 16 POKE 755,0 20 XP=10:YP=12 30 MX=RAND(40):MY=RAND(20) 39 REM PLAYER STATS 40 DEX=20:STR=30:VIT=25:CLV=1:AC=10:MINW=4:MAXW=12:LIFE=2*VIT+2*CLV+18 49 REM MONSTER STATS 50 MAC=5:MTH=10:MIND=2:MAXD=5:MHP=30:MLV=2 100 DO 110 CLS 120 EXEC SET_PLAYER 140 EXEC MOVE_MONSTER 150 EXEC TEST 160 POSITION 20,0:PRINT "MONSTER HP:";MHP; 170 POSITION 20,1:PRINT "PLAYER HP:";LIFE 900 PAUSE 5 999 LOOP 1000 PROC SET_PLAYER 1010 POSITION XP,YP 1020 PRINT "O"; 1030 IF STICK(0)=7 THEN XP=XP+1 1040 IF STICK(0)=11 THEN XP=XP-1 1050 IF STICK(0)=13 THEN YP=YP+1 1060 IF STICK(0)=14 THEN YP=YP-1 1070 ENDPROC 1100 PROC MOVE_MONSTER 1110 IF MX<XP THEN MX=MX+0.5 1120 IF MX>XP THEN MX=MX-0.5 1130 IF MY<YP THEN MY=MY+0.5 1140 IF MY>YP THEN MY=MY-0.5 1150 POSITION MX,MY:PRINT "X"; 1160 ENDPROC 2000 PROC TEST 2010 IF XP=MX AND YP=MY 2020 FTH=50+(DEX DIV 2)+CLV-MAC 2030 IF RAND(100)<FTH THEN POSITION 0,0:PRINT "HIT!" 2040 DAMAGE=RAND(MAXD-MIND+1)+MIND 2050 CHARDAM=(STR*CLV) DIV 200 2060 DAMAGE=DAMAGE+CHARDAM 2065 MHP=MHP-DAMAGE 2070 POSITION 0,0:PRINT "HIT ";DAMAGE 2080 ENDIF 2099 REM MONSTER HITS PLAYER 2100 IF XP=MX AND YP=MY 2110 FTH=30+MTH+2*MLV 2120 A=DEX DIV 5+AC+2*CLV 2130 B=FTH-A 2140 IF B<15 THEN B=15 2150 IF RAND(100)<B 2160 DAMAGE=RAND(MAXD-MIND+1)+MIND 2165 POSITION 0,1:PRINT "ZOMBIE HIT ";DAMAGE; 2170 LIFE=LIFE-DAMAGE 2180 ENDIF 2190 ENDIF 2999 ENDPROC TBASIC.zip Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted July 5, 2006 Share Posted July 5, 2006 Awesome! Looks like some of the first BASIC games I wrote twenty years ago! Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 5, 2006 Author Share Posted July 5, 2006 diablo is a basic game... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 6, 2006 Author Share Posted July 6, 2006 here is another prototype. this time completly written in assembler... sorry for the flickering but its just a prototype... it was far easier in assembler than thought. it took me longer in turbo basic than in assembler... this can easily be turned into a small "arena" game like robotron... i have included a well documented assembler source code for xasm... (well...at least for me its well documentated) next will be to implement item dropping.... excuse me for the lame gfx... its not zx81... its just for getting the game mechanics done... instructions: a random monster ("R") tries to catch you. if it hits you it tries to attack you. you can move around with the joystick. but you can attack the monster as well by hitting it and pressing fire. on the left side its your life bar. if its zero you are dead and the game is over... you must reboot to restart. the monsters hit points are on the right side. when you killed the monster another one appears and so on... ps. the flickering is caused by the screen routines...not by the calculations... they can be done really fast in assembler... diablo1.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 6, 2006 Author Share Posted July 6, 2006 (edited) ok. small update for the guys who think i am crazy... here with sprites done by Cybernoid... note. without any flicker now... diablo1.zip Edited July 6, 2006 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
Cybernoid Posted July 6, 2006 Share Posted July 6, 2006 (edited) ok. small update for the guys who think i am crazy... here with sprites done by Cybernoid... This is great work! Don't think you are crazy! Although, maybe I am crazy for helping. Anyway, the graphics were actually done by Adam (Powrooz)... And they are great! Here is a small update for the dungeon generation... you can keep hitting a key after each dungeon to see another. I am working on the wall code. This now fixes the border bugs and is much faster on the room generation... dungen.zip Edited July 6, 2006 by Cybernoid Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 6, 2006 Author Share Posted July 6, 2006 one question regarding the map. if you compare my gr.11 map with yours then could it be possible that you don't have 45 degree? i mean if you compare your wall it looks like that one wall tile (pixel) consists of 2 pixel instead of one. i am asking that because in my mapper 2 wall tiles are not allowed to be next to each other... so XX.. should be avoided ..XX instead X... .X... doesnt matter regarding gr.11's 4:1 ratio. Quote Link to comment Share on other sites More sharing options...
Cybernoid Posted July 6, 2006 Share Posted July 6, 2006 Yeah, I know. I still need to fix the horizontal ratio. It is use the full byte as one X location instead of 4 bits. Are you sure you want to use only 4 bits for the tile? If you use the full byte, then you will have 256 tiles available instead of 16. And, this will make the dungeon generation code simpler. Just a thought... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 6, 2006 Author Share Posted July 6, 2006 256 bytes per tile... of course much simpler... but needs hell shit of memory... 16k for a 128x128 map... killer for a 5200 version... Quote Link to comment Share on other sites More sharing options...
miker Posted July 6, 2006 Share Posted July 6, 2006 (edited) Hehe, you can always pack the levels. Or maybe think about some way to equip 5200s with disk drive... Edited July 6, 2006 by miker Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 6, 2006 Author Share Posted July 6, 2006 btw. expect to have tonight another playable version with item dropping and real sprite handling (background buffer) and gold counter + experience points... working title of this prototype "Beyond Evil - Arena Wars" Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 6, 2006 Author Share Posted July 6, 2006 miker. yup...of course you can... but Fox' packer needs a lot of ram as well Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 6, 2006 Author Share Posted July 6, 2006 little progress... i have implemented a background buffer for the sprites... as you can see it does not work correctly. why? before setting a sprite i am copying the underlaying chars from vram into the background buffer. then the sprite is set. next frame i am restoring the background back into vram and so on... but of course this does not work when the 2 sprites overlapping both the background as the sprite setting routine does not know which sprite has priority. so its kind of zbuffer... but what i am not doing at the moment is checking if the background buffer has any elements already... so...anyway. it does not matter... i had to avoid any overlapping anyway. so now i need your brain... (my one runs slow at the moment...) how can i quickly check if sprites are overlapping just by their mx,my and px,py screen coordinates? something like abs(px-my)>=2 must be the solution but is rather complicated in assembler.... any ideas, solutions etc welcome... btw. in the latest build item dropping is enabled... diablo1.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 6, 2006 Author Share Posted July 6, 2006 well... but i have to have in mind that there will not only one monster on screen but more... so another way to consider would be to work with a sprite buffer holding the background for each sprite (not a background buffer) but this could be time consuming... another solution could be to avoid any overlapping like in gauntlet... but this would require additional tests for each monster. of course the player must be enabled to pick up stuff.... Quote Link to comment Share on other sites More sharing options...
Cybernoid Posted July 6, 2006 Share Posted July 6, 2006 256 bytes per tile... of course much simpler... but needs hell shit of memory... 16k for a 128x128 map... killer for a 5200 version... Yeah, it takes a lot. But, it would still be 8k for a 128x128 map using 4bits.... I will modify the dungeon generation code for 4bit and walls... though. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 6, 2006 Author Share Posted July 6, 2006 if memory gets really tight then we can implement RLE packing... as this needs no big buffer and can be depacked straight away. let it be 1 byte / tile. Quote Link to comment Share on other sites More sharing options...
Cybernoid Posted July 6, 2006 Share Posted July 6, 2006 Okay. That makes sense. We just need 16k somewhere in the memory for a 128x128 map. We don't need to include it in the binary at boot. The code will write into a 16k buffer. Hmm, I wonder if we can generate only a portion of the map at a time... For the 5200, if you want to think about it... you could limit the map to be 128x64 for 8k or 64x64 for 4k. --C Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.