Jetboot Jack Posted April 29, 2005 Share Posted April 29, 2005 I'd like to point out that the Project Xanthien Sprite Multiplexer does NOT work the same way as the ones in Ms Pac Man or Joust... The PX multiplexer is not a ring/resuse and therefore flicker system, but uses horizontal timing loops to resuse a sprite on the SAME line twice - so it can display 8 mono 8bit sprites or 4 multicolor 8bit sprites, plus 4 missiles PER scanline... sTeVE Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 29, 2005 Share Posted April 29, 2005 I'd like to point out that the Project Xanthien Sprite Multiplexer does NOT work the same way as the ones in Ms Pac Man or Joust... The PX multiplexer is not a ring/resuse and therefore flicker system, but uses horizontal timing loops to resuse a sprite on the SAME line twice - so it can display 8 mono 8bit sprites or 4 multicolor 8bit sprites, plus 4 missiles PER scanline... sTeVE 846279[/snapback] but in theory you can not put all 4 multicolour sprites beneath each other as you need CPU for repositioning? is it flexible enough f.e. for a delta like shoot em up? Quote Link to comment Share on other sites More sharing options...
TMR Posted April 29, 2005 Share Posted April 29, 2005 i mean multiplexing & ring buffering on c64? Possibly yes but there's not much point really, the C64 puts eight hardware sprites on a line with a reasonable size, ring buffering was pretty much for hardware with smaller sprites where they needed to work together (like the NES) to get a reasonably sized object - eight 12 pixel wide objects a line is more than enough to avoid fluffing the plex for 95% of the time as long as some care is taken about placing of objects. Quote Link to comment Share on other sites More sharing options...
emkay Posted April 29, 2005 Share Posted April 29, 2005 but in theory you can not put all 4 multicolour sprites beneath each other as you need CPU for repositioning? is it flexible enough f.e. for a delta like shoot em up? 846298[/snapback] "beneath" is never a problem "aside" is possible.... just with the cost of "sprite higth" for multiplexing per scanline. Quote Link to comment Share on other sites More sharing options...
analmux Posted May 2, 2005 Author Share Posted May 2, 2005 I'd like to point out that the Project Xanthien Sprite Multiplexer does NOT work the same way as the ones in Ms Pac Man or Joust... The PX multiplexer is not a ring/resuse and therefore flicker system, but uses horizontal timing loops to resuse a sprite on the SAME line twice - so it can display 8 mono 8bit sprites or 4 multicolor 8bit sprites, plus 4 missiles PER scanline... sTeVE 846279[/snapback] but in theory you can not put all 4 multicolour sprites beneath each other as you need CPU for repositioning? is it flexible enough f.e. for a delta like shoot em up? 846298[/snapback] ...hmmmm, this has also been discussed long before (multiple times). You'd ALSO need extra CPU cycles to stuff new graphics in the Player's Shape registers: that's not possible. Certainly not in antic 4 modes where 1 in 8 scanlines doesn't allow the CPU to work in the onscreen (timezone/) area. So forget 8 players per scanline: Just calculate with me: 4 new player x positions, 4 new player shapes = 8 stores = LDA # $xx; STA a $xxxx = 6*8=48 cycles at least, where we just have less than 40 cycles (onscreen) available: No Way! ..........And don't forget to Reposition the sprites again at the end of the scanline. Maybe a 5th (or even a 6th) player but not 8. Quote Link to comment Share on other sites More sharing options...
analmux Posted May 2, 2005 Author Share Posted May 2, 2005 personally I don't see why the Atari 8-bit can't do a decent rendition of mayhem in monsterland. Actually... The more I am trying to explain, where the "lacks" are and the more I am doing "new" stuff... the more I am shure, that all this isn't really wanted, even if coders could do so. The problem starts where the known old "ATARI"-style begins and it ends, where everything "new" is a bad and ugly thing ... Well... I'm not the kwiesatz haderach in making music, but my demonstrations should have done very well, especially if musicians recognize the possibilities and mixing them with their knowledge.... Or... the other thing with the "sadness" 24h contest at ATARIAREA... Which shows very clear, that "real managing of the possibilities" is not wanted either. The appended file contains another combination of G2F & RMT with the sadness theme..... Excluding the taste and my skills in making music, there is a colorful non-flickering picture with cool "instruments" in the "background Music" , and there is approx. 50% CPU cycles unused.... But, who cares? 843709[/snapback] Well, excuse me, but you can't expect that now all in a sudden there will be written new software with the new (revolutionary) techniques. You should at least wait another 3 years before any homebrew developers have had the time to create something at all. You must realize that most of these people don't have the (fulltime-365-days-a-year) job to create new atari 8bit software. We all have another life besides atari. I'm very sure that no-one here has a life COMPLETELY dedicated to the atari. (like me, I'm still young and very easily distracted and don't even WANT to put too much time into my atari hobby) Don't get me wrong emkay: I (and maybe a lot of other atarians here) have respect for guys like you that try to get some new stuff out of the machine, so that's totally not the point. And I personally would very much like to see a new generation of atari 8bit software with the new techniques. But we should all be patient. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 2, 2005 Share Posted May 2, 2005 i was just refering to jetboot's reply regarding his horizontal multiplexor in his game. Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted May 2, 2005 Share Posted May 2, 2005 On ANY scanline in PX all 4 multicolor sprites are drawn, but no graphic chnages per resuse, color changes only... When more than 2 designs or more than 4 sprites are required you will notice PMG drop out, since no other type of multiplexing is used... The main character in PX is a software sprite with missiles overlaid for the extra color sections... sTeVE Quote Link to comment Share on other sites More sharing options...
analmux Posted May 2, 2005 Author Share Posted May 2, 2005 On ANY scanline in PX all 4 multicolor sprites are drawn, but no graphic chnages per resuse, color changes only... When more than 2 designs or more than 4 sprites are required you will notice PMG drop out, since no other type of multiplexing is used... The main character in PX is a software sprite with missiles overlaid for the extra color sections... sTeVE 848025[/snapback] I'm sorry but in the PX demo Tebe posted earlier in this thread I can see more than 2 multiplayer sprites on the screen but not more than 2 on the same scanline ??? Quote Link to comment Share on other sites More sharing options...
analmux Posted May 2, 2005 Author Share Posted May 2, 2005 ...Oh, and another thing: [offtopic] I'd like to say that today I have installed internet at my home PC, so I'm back in town. [/offtopic] Quote Link to comment Share on other sites More sharing options...
tebe Posted May 4, 2005 Share Posted May 4, 2005 Multiplexer v1.1 multiplexer_example.zip -> use MADS v1.6.1 for compile this source code http://g2f.atari8.info/mads/ multiplexer_example.zip multiplexer.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 4, 2005 Share Posted May 4, 2005 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? Quote Link to comment Share on other sites More sharing options...
tebe Posted May 4, 2005 Share Posted May 4, 2005 (edited) i can't see any "test sprites" in the multiplex.exe like you have on the screenshots? (the white squares???) white squares = sprites (solid color) 1. click button GENERATE 2. click image (left mouse button) 2nd question... in which language are you writing this small tools? Delphi 7.0, program is very fast on P42.8, slow on Cel655 Edited May 4, 2005 by tebe Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 5, 2005 Share Posted May 5, 2005 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 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 5, 2005 Share Posted May 5, 2005 oh...and you can halt the action on screen by pressing & holding START.... Quote Link to comment Share on other sites More sharing options...
analmux Posted May 7, 2005 Author Share Posted May 7, 2005 @ Heaven: Clever Routine !!! Here: I've modded the .asx a little bit to see just the players: bar shaped vertical areas. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 9, 2005 Share Posted May 9, 2005 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... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 9, 2005 Share Posted May 9, 2005 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... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 9, 2005 Share Posted May 9, 2005 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... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 9, 2005 Share Posted May 9, 2005 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. 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.