Tezz Posted June 8, 2008 Share Posted June 8, 2008 I'm just now reading through the latest discussion from the last few days.. before which I must congratulate Germany on their win tonight! It was an entertaining game like Portugal yesterday.. maybe this will be their year as most are predicting Quote Link to comment Share on other sites More sharing options...
Tezz Posted June 8, 2008 Share Posted June 8, 2008 It's a very good approach to take for the game with the "bitmap" screen, i'm just looking at the sources now. definately best for sure whenever possible to avoid preshift for the benfit of not needing masses of bytes! I like the way it's going. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 14, 2008 Author Share Posted June 14, 2008 ok. played around with the new code... assume the following we have a background buffer holding information if a position is possible or not (remember the "gr.0" screenshots). so the main move routine is doing this get new position check if new position is free (bgr buf=0) yes, then erase old position in bgr buf and draw bitmap on old position to erase the old one then draw the new bitmap at new pos and set the bgr buf. if bgr buf<>0 on new position then skip the sprite setting (as it is drawn last time anyway). so... but now i run into this situation. the background buffer is based on char positions and not pixel positions so...assume following oldpos 0,0 newpos 1,0 the background buffer is the same as the char pos. so actually I would need to erase the oldpos anyway each time I do the check? or does anybody have a better idea? Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 14, 2008 Share Posted June 14, 2008 Err... the problem that can arise is with fine movement. It will mean the collision buffer doesn't always change but the number of pixels in the sprite has a bearing. e.g. a 4 pixel wide player can occupy 1 or 2 characters horizontally. a 5 pixel wide player will always occupy 2 characters horizontally. a 6 pixel wide will mostly occupy 2, but sometimes 3. similar situation applies in the Y direction. The question may be - is it worth checking fine changes in position to see which collision buffer characters don't need to be altered? For smallish objects, doing so would probably use as many or more cycles than just doing an erase and redraw to the backbuffer/collision buffer. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 14, 2008 Author Share Posted June 14, 2008 hmmm.... haven't found any practical solution yet but maybe I will do a simple turbo basic test... but I am sitting here with my eee-pc and haven't any atari800 emu here running... one quick idea could be that i am not testing for 0 but for "sprite nr" as well somehow... but now i am watching sweden vs spain... so many of my PES4 players (former barca players esp. larsson, xavi, iniesta etc...) Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 14, 2008 Share Posted June 14, 2008 I guess there might be some table-based way to check if the backbuffer needs updating. For 4 pixel wide sprites, pretty easy - keep track of (X AND 3). If it goes from non-zero to zero, or 0 to non-zero then it's moved characters. 5 pixel wide: (X AND 3). If it goes to or from a value of 3, then it's moved. 6 pixel: To or from a value of 2, or from 0 to 3. 7 pixel: To or from a value of 2, or from 0 to 3. 8 pixel. Same as 4 pixel. Then similar process for Y. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 14, 2008 Author Share Posted June 14, 2008 well... my check backbuffer is ORAing all 9 cells together, so if result is 0 then it's new pos is empty but if occupied by an enemy of course <>0. now assuming that each cell holds the sprite no+128 i will simply check against the actual sprite no as well and see if that solves the issue. Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 15, 2008 Share Posted June 15, 2008 Maybe you could somehow optimise the collision check. e.g. when moving to the right, you should really only need to look at "new" positions to the right of where the player already is. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 15, 2008 Author Share Posted June 15, 2008 updated DIS6502 workfile for Gremlins... more labels added... as I understood the code it does the same like me...first clear backbuff, checks new pos and sets backbuff... but haven't played around with the code so far... gremlins.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 15, 2008 Author Share Posted June 15, 2008 (edited) small progress... it is key to setup the first "frame" correctly so everything goes right after the game engine is running. Have a look on the code. I have included the source + everything to assemble the example for you to double check. press START to show the back buffer, press OPTION to stop the action on screen to have a closer look. with the joystick you can move one gremlin around. I have adjusted the checks so on YPOS AND 7=0 only 3 rows instead of 4 are checked so now you can get closer to each Gremlin. and there is a virtual "wall" in the middle of the screen that's why you can not cross the middle. but you can see the wall when pressing OPTION. the next implementation I will try to give the nasties a little bit intelligence so they turn around when hitting the walls etc. the colour bars represent one "font"-area, so when crossing one of such zones the "draw split" has to be used as we have to write the gfx data in 2 different fonts. why the hell I am doing this you may ask? assume that the Gremlins will become Snakes, Skelettons, etc... assume that the "player controlled" Gremlin become the Knight. Assume that the virtual wall become a "real" wall like in the earlier Beyond The Evil builds... and you might see where I am heading to... it's easier to test the new gfx engine in such a "controlled" environment than in the complete game yet... sprite7c.zip Edited June 15, 2008 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 16, 2008 Author Share Posted June 16, 2008 another interesting thing spotted in Gremlins, start f.e. in higher levels (f.e. 12 onwards) then you see that Gremlins does not move every monster but only the ones which are near of the player... this would fit into my already "line of sight" algorithm. Quote Link to comment Share on other sites More sharing options...
JamesD Posted June 17, 2008 Share Posted June 17, 2008 The Gremlins approach brings up an interesting point. You don't need to update data every frame. If you only have to calculate distance & line of sight for 1 sprite each frame that takes a lot less time and lets you have a lot more sprites on screen at a time. Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 17, 2008 Share Posted June 17, 2008 I think Robotron uses a similar approach (?) It actually looks alright - makes it look like they're marching towards the player. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 17, 2008 Author Share Posted June 17, 2008 James, you would need to calculate the Line of Sight for every monster and every frame as you want to know which is around the player... but I guess that Gremlins does it the otherway around like I have done...as I calculate for each nasty the line of sight, f.e. snakes have lower line of sight than f.e. skeletons... Gremlins seems to calculate the player line of sight as the player is activating the monsters around him... this could work in a game like Gremlins as they are only 1 type of monster but with different types? Quote Link to comment Share on other sites More sharing options...
urborg Posted June 17, 2008 Share Posted June 17, 2008 (edited) But different monsters can have the same line of sight. It would simplify everything. In Gremlins you have in fact two types of monsters: Gremlins and Moogwies. Edited June 17, 2008 by urborg Quote Link to comment Share on other sites More sharing options...
urborg Posted June 17, 2008 Share Posted June 17, 2008 (edited) Sorry, entered by a mistake. I wanted to remove this post, but I don't know how? Edited June 17, 2008 by urborg Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 17, 2008 Share Posted June 17, 2008 Just edit and put "*** double post ***". Then follow it up with some generic curse about your browser, network connection, ISP, forum software etc. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 17, 2008 Author Share Posted June 17, 2008 Urborg, but we want to have different line of sight for each monster type??? ;=) Quote Link to comment Share on other sites More sharing options...
JamesD Posted June 18, 2008 Share Posted June 18, 2008 James, you would need to calculate the Line of Sight for every monster and every frame as you want to know which is around the player... Why? At 50/60 frames/sec and far fewer baddies on screen than there are fps you would still be updating the info at least 5 or 6 times/sec. If you are only moving 1 / frame anyway why does it even matter whether or not you know if the others are in range... they aren't going to move yet anyway. but I guess that Gremlins does it the otherway around like I have done...as I calculate for each nasty the line of sight, f.e. snakes have lower line of sight than f.e. skeletons... Gremlins seems to calculate the player line of sight as the player is activating the monsters around him... this could work in a game like Gremlins as they are only 1 type of monster but with different types? I don't think it's a question of whether or not it will work but just how best to implement it. Quote Link to comment Share on other sites More sharing options...
JamesD Posted June 18, 2008 Share Posted June 18, 2008 Urborg, but we want to have different line of sight for each monster type??? ;=) I'm sure different monsters might see further but I don't see why 1 routine can't handle that. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 23, 2008 Author Share Posted June 23, 2008 (edited) Jesus, another year passed by since Espire & PG made some mockups... damned real life... but still working on the sprite & gfx engine... right now I am preparing the gfx for the new engine... Edited June 23, 2008 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 23, 2008 Author Share Posted June 23, 2008 ok. I am just playing around with a "put char" routine... I thought it is easier but I am stucked... can someone think about a nice algorithm how to calculate the char adress of the 8 fonts when the routine is looking like this: ;puts one char on screen(x,y) ;in x,y ;in a = char tile no draw_char: pha tya asl asl asl tay clc lda linetabl,y adc collumtabl,x sta v1 lda linetabh,y adc collumtabh,x sta v1+1 pla tax lda chartabl,x sta v0 lda chartabh,x sta v0+1 ldy #7 draw_char0 lda (v0),y sta (v1),y dey bpl draw_char0 rts clear_screen: lda #23 sta tempy clear_screen0 lda #39 sta tempx clear_screen1 lda #2 ldx tempx ldy tempy jsr draw_char dec tempx bpl clear_screen1 dec tempy bpl clear_screen0 rts so remember that the screen is divided into 8 font areas each covering 3 lines in order font 0:AD... font 0:BE... font 0:CF... font 1:AD... font 1:BE... font 1:CF... font 2:AD... font 2:BE... font 2:CF... ... Maybe I am too tired at the moment but maybe some of you can give me a hint... and here are my lookup tables: org linetabl;starting font based on YP (F=(YP DIV 24)*1024+$8008) :256 .byte <[[#/24]*1024+font+8] org linetabh :256 .byte >[[#/24]*1024+font+8] org collumtabl :64 .byte <[#*24] org collumtabh :64 .byte >[#*24] org linetab2l :32 .byte <[#*40+background] org linetab2h :32 .byte >[#*40+background] org chartabl :256 .byte <[#*8+font8] org chartabh :256 .byte >[#*8+font8] I am prefering a simple, compact routine which can be slow as the screen is build up anyway once when player enters new room... (again...see Gremlins... ) Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 23, 2008 Share Posted June 23, 2008 (edited) When indexing into multiple charsets, the low byte will be the same regardless of the CHBAS origins. For the high byte, having the first chset on an 8K boundary might help. e.g. $8000 Then you just need to get the initial high byte index, and have a table of values which get ORed with that. e.g. for the first chset, origins for characters at (0,0) (0,1) (0,2) will be $8000, $8140, $8280 Table of values to be ORed with the high address byte (repeat each 3 times): 0, 4, 8, C, 10, 14, 18, 1C Edited June 23, 2008 by Rybags Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 24, 2008 Author Share Posted June 24, 2008 Thanks Rybags. Will have a look. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 24, 2008 Author Share Posted June 24, 2008 but I should have the "put char" procedere anyway as it's nearly the same for the sprite routines... except that i do not split the draw on region boundaries. the "sprite" has 4x8 instead of 12x21... so I should have everything in place... 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.