Heaven/TQA

great work... haven't noticed that you can move around... but why are the rasters flicker? the jump/move behaviour is great! feels right... maybe analmux should take this for the mario game.

it makes the code more compact so your mentioned "pseudo code" mva sortsprx,x stack,x+ should be assembled to lda sortsprx,x sta stack,x inx btw. the code was written in notepad and wasn't tested or assembled. it grew just in my head this morning...

mva is XASM specific and will be assembled to LDA, STA ("Move Value with Accu") and ",x+" is a post increment and will be assembled to "command, INX" f.e. sta adres, x+ STA adress INX sorry.... i thought this is clear.

i think this works better: ;DLI zone 1 mva sortsprx stack mva sortsprx+1 stack+1 mva sortsprx+2 stack+2 mva sortsprx+3 stack+3 sta ll+1 ldy #4 loop lda sortspry,y sec ll sbc #[next spr] cmp #8 ;vertical size of sprite bcs no_overlap ;if y2-y1<8 then they do overlap lda sortsprx,x sta stack,x inx cpx #max_sprites bcc loop no_overlap stx cue ;saves for the VBL how many sprites are per zone txa tay ;DLI zone 2 mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ sta ll+1 loop lda sortspry,y sec ll sbc #[next spr] cmp #8 ;vertical size of sprite bcs no_overlap ;if y2-y1<8 then they do overlap lda sortsprx,x sta stack,x inx cpx #max_sprites bcc loop no_overlap stx cue+1 ;saves for the VBL how many sprites are per zone txa tay ;DLI zone 3 mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ sta ll+1 loop lda sortspry,y sec ll sbc #[next spr] cmp #8 ;vertical size of sprite bcs no_overlap ;if y2-y1<8 then they do overlap lda sortsprx,x sta stack,x inx cpx #max_sprites bcc loop no_overlap stx cue+2 ;saves for the VBL how many sprites are per zone txa tay ;DLI zone 4 mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ sta ll+1 loop lda sortspry,y sec ll sbc #[next spr] cmp #8 ;vertical size of sprite bcs no_overlap ;if y2-y1<8 then they do overlap lda sortsprx,x sta stack,x inx cpx #max_sprites bcc loop no_overlap stx cue+3 ;saves for the VBL how many sprites are per zone ... the VBL can now flicker through the display stack and prepare the DLI flags to handle the display properly. Of course it must copy the sprite data in the correct player/missle area but this should be no problem at all as we move data in to the players in the order 4,3,2,1,4,3,2,1 etc... --> MS Pac Man Atari 800.

what do you think of this? ;XASM 6502 source code format ;you have to know about the atari800 hardware (4 player (8x256), 4 missles (2x256). ;DLI zone 1 mva sortsprx stack mva sortsprx+1 stack+1 mva sortsprx+2 stack+2 mva sortsprx+3 stack+3 sta ll+1 ldx #4 loop lda sortspry,x sec ll sbc #[next spr] cmp #8 ;vertical size of sprite bcs no_overlap ;if y2-y1<8 then they do overlap lda sortsprx,x sta stack,x inx cpx #max_sprites bcc loop no_overlap stx cue ;saves for the VBL how many sprites are per zone ;DLI zone 2 mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ sta ll+1 loop lda sortspry,x sec ll sbc #[next spr] cmp #8 ;vertical size of sprite bcs no_overlap ;if y2-y1<8 then they do overlap lda sortsprx,x sta stack,x inx cpx #max_sprites bcc loop no_overlap stx cue+1 ;saves for the VBL how many sprites are per zone ;DLI zone 3 mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ sta ll+1 loop lda sortspry,x sec ll sbc #[next spr] cmp #8 ;vertical size of sprite bcs no_overlap ;if y2-y1<8 then they do overlap lda sortsprx,x sta stack,x inx cpx #max_sprites bcc loop no_overlap stx cue+2 ;saves for the VBL how many sprites are per zone ;DLI zone 4 mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ mva sortsprx,x stack,x+ sta ll+1 loop lda sortspry,x sec ll sbc #[next spr] cmp #8 ;vertical size of sprite bcs no_overlap ;if y2-y1<8 then they do overlap lda sortsprx,x sta stack,x inx cpx #max_sprites bcc loop no_overlap stx cue+3 ;saves for the VBL how many sprites are per zone ... the VBL can now flicker through the display stack and prepare the DLI flags to handle the display properly. Of course it must copy the sprite data in the correct player/missle area but this should be no problem at all as we move data in to the players in the order 4,3,2,1,4,3,2,1 etc... --> MS Pac Man Atari 800. the DLIs can reposition the sprites each VBL... the DLI (Rasterinterrupts) will be set to each zone where the next free sprite can be displayed without any overlapping... sortsprx,y contain the virtual sprite positions after they have been sorted by y-pos. what do you think? now it should be easy to flicker through the display stack for each zone as the CUE table contains the virtual sprites per zone...

World Of Warcraft = WOW...

ehmm.... read the FAQ and Philip's email regarding the other titles planned... esp. Destiny: "Fighting with high tech equipment (from both revelation, destiny and if you run into the aliens that politically are friendly to you plight, the weapons the riddler has from the dungeon). Searching further this immense ship you discover a chamber filled with metal cocoons. Using wit and knowledge gain through other locations you decipher the controls and the display. You learn that these cocoons hold bodies, the bodies of all of those captured. The machines keep the bodies physically alive and fit, but imprisoned. The minds of those entrapped are tapped and fed with images. The ships computer can even permit the images to interact with solid/material components of the ship. You are an image. What is reality? You body lies in a cocoon. Your mind sees what the image sees. What is a soul? What is experience? You experience, you feel what this image you have been controlling since you kidnapping feels. Again there are choices to make. In the end you are left with many choices, continue to live in you image body, a nearly immortal life, but knowning that these aliens have done this to you and can watch, feel, experience whatever you do whenever they want. You are their entertainment. They have become jadded by luxury, power and knowledge and use lesser beings to regain some of the passions of life. You can cut off this channel, though they may also destroy the ship, or earth. You can escape in a smaller ship than the entertainment world and go back to earth (hoping to evade the future capture ships these beings send to gain more 'entertainment'. You could destroy the planet [and hope that they are not a multiplanet race] You can take the entertainment world (that was orbitting the alien's planet) and bring it back to earth to let the scientist learn from it [and hope the aliens don't trace it]. You could blackmail the aliens. You could sell out humanity. You could try to bluff them. There are many choices, life isn't easy and some of the most important decision are the hardest to find a best answer in." ehm...to which motion picture blockbuster reminds me that???

and as a demo lover & coder i was impressed by the intro and the well used atari features.... and i could sing the intro song... "the waves are pounding on the shore..."

we spent weeks playing AR (city/dungeon) but i was more into dungeon than city... but friend of mine was addicted to the city... he even do not go to school when playing... last weekend we had a chat about AR when we talked about WOW... and he told more stories like he spend weeks to get all for his "hammer" like weapon...and when going to the guy who makes the weapon he told him that the weapon will be ready in 2 weeks... REALTIME... unbelievable... maybe after playing WOW and ultima i should play little bit AR... i love the thunder and lighting and yes... i have bought a second 1050 as well just to avoid disk swapping (as my switch broke...)

and the debug line shows that sprite 8+9 are marked for rejection ("!" is deleted in the line...) which is not true either as the engine should mark only sprite 9 causing the conflict...not both.

here is an example screen showing conflicts which the engine should avoid: (it's a basic engine feature without the "inteligent flickering" implemented) the sorted y-position table looks like: dli1: 27,28,28,2e dli2: 3b,58,5b,65 dli3: 67,67,6e,80 dli4: 96,a2,a7,ae i have marked the bugs... as you can see we have a conflict in zone 2+3... sprite 8 and 12 ("N" and "Q") are merged together which the engine should avoid... the reason for this is that sprite 9 ("B") comes too close to sprite 8 ("N"). so the check failed here when setting the DLI bits... sprite 9 should be rejected when it comes too close to 8 to avoid any grafix garbage.... so let's have a look into the code... mapper_a lda sortspry+8 ;set DLI for sprites 8-12 bne mapper_bb lda sortspry+9 bne mapper_bb lda sortspry+10 bne mapper_bb lda sortspry+11 bne mapper_bb jmp copy ah...here we go... this check does not work anymore as i am using a separate table (sortsprvisible) for testing if a conflict apeared for a specific sprite... have to check when i am back home...

and if you are asking yourself why the hell i am spending my time with this and not Boinxx i can tell you why... this routine will be used in Boinxx somehow... so stay tuned...

i dont know if you have realised that when running in "10% performance" mode of atari800win you realise when the engine is doing something wrong. i have to double check it more intensivly as far as i remember i have implemented a check for the mapper when sprites are close and get marked for rejection... but what i haven't checked what happens when 2 DLIs are getting to close... just from logic point of view: sprites get rejected when they are overlapping so <8 pixels... and a DLI secure value is calculated as well (by default 8 scanlines)... so there must be a bug as imho there should be no DLIs beneath each other? (recognisable by the white lines getting very close to each other)... hmmm... have to check when i am back home...

very impressive... no flickering, scrolling and kind of "font" system... i am impressed (ok. not knowing too much about the 2600 but TIA suxx imho compared to every other video chip based system... ) i can remember one of the 1st levels where a lot of diamonds are falling down from the top... will there be enough power to display many movements or will the engine going down? what about many butterflies??? how many can be handled? is it just your TV set or does it looks like a b/w game?

holy shit its this impressive for good old 2600... unfortunatly with 4pixel grafix you can not catch too much of the original gfx... and look... but it's quite cool. but i think everybody recognises the butterflies...

here are more theory: http://www.atariage.com/forums/index.php?s...pic=66811&st=25

thanks manuel... question: when you are refering to "just move through my sorted list and display..." what exactly are you meaning? i mean... f.e. if your sorted list is: 1,2,3,4,[5] ; assuming 4 hardwaresprites 5th sprite is marked as "rejected" how would you walk through this list? in my test i am sorting every frame 16 randomly moving sprites and map them to 4 hardware sprites... rejecting overlapping ones which could not fit on the scanline... and now i am searching for a method (f.e. MSX ringbuffer method...) to display the rest... examples on atari8bit are ms pacman & joust as most knewn commercial games doing this kind of "intelligent flickering".

but how do you "inteligent flicker"???

uj...you are using bubble sort??? strange... i am using a derivate of radix sorting: http://www.student.oulu.fi/~loorni/covert/rants/sprite.htm how does the sheduler or "mapper" work? oops. sorry should now be moved into programming forum...

ah...sorry... i should not start from beginning but instead from your mentioned march 2002... aha...sorting is discussed as well... good that i have a sorter implemented as well...could be not wrong...

danke, thomas. but i haven't found any logical description or even source code? i went through several pages...maybe you can point me to post directly??? i would need information how the actual flickering is done, f.e. flicker through the virtual sprites which share the same scanline...

hi, sorry to post this here but you might popped by this: http://www.atariage.com/forums/index.php?s...pic=68025&st=25 we are discussion several methods in enhancing atari's sprite capabilities... actually i am dealing with sprite multiplexing via raster interrupts and i was wondering how you 2600 guys handle the mutliplexing & kernel? f.e. joust, asteroids or pac man are using kind of flickering when more than 2 hardwaresprites are on one scanline... how are you dealing with it? maybe there is a kind of effective approach which i could adapt...

oh...and you can halt the action on screen by pressing & holding START....

ok. small interims work in progress... including some debug information... at the bottom of the screen you see "!" signs which indicate which sprite is possible to display. if there is no "!" then the mapper marked the sprite for the DLI routine for rejection... this info might be usefull when the ringbuffers are going to be implemented... the white lines are the DLIs and are splitting the screen most of the time into 4 zones... my idea is to have for each zone a 16 byte ringbuffer (as a worse case scenario all 16 sprites could be on the same line)... the mapper is filling up each zone as the mapper knows which sprite and which DLI he is proceding... so the DLI whill be slightly adapted so it loads the sprite informations not from the sorted list but from the ringbuffers... as the DLI knows in "which zone" he is anyway this should be no problem... cycling will be handled by the VBL starting every 4th sprite of the ringbuffer... this is the idea...might be worth a try... just in comparison to Tebe's approach... please have in mind that his tool & code is absolutly precaclulated so he avoids any conflicts... the tables generated do not have any positions causing overlapping sprites... just to have that in mind compared to my one... and of course...the included source is NOT optimised yet... plex7b.zip

thanks tebe... 2 questions: i can't see any "test sprites" in the multiplex.exe like you have on the screenshots? (the white squares???) should they come when i am pressing "test..."? 2nd question... in which language are you writing this small tools?