Heaven/TQA

best is always going as much native as you can... so composing via a standard PC music creation software like cubase, etc... should be no problem but then you have to import your melodies into an atari native tracker to get the best out of it... and for guys coming from PC RMT seems the best... if you get into it how in general a tracker works (check out PC trackers f.e. as well...) then you can go native with atari specific music software like music pro tracker (MPT), Theta Music Tracker (TMC) or even CMC...

i was just refering to jetboot's reply regarding his horizontal multiplexor in his game.

thanks dan... some of your thoughts i had yesterday as well... (f.e. frame counter per sprite or cue). my sprites have all the same resolution 8x8 so you can compare which one are overlapping and which not... i wanted to avoid too much DLIs as for my 16 sprites example you would need maximum of 4 zones e.g. DLIs to split them up (4x4 =16). Raster, coder of RMT, mentioned last year that in an older demo of him he worked with this "slot" concept... so i have to rethink... dan, but think of several conditions f.e. all 16 sprites on different y-positions not overlapping all 16 sprites on same y-position etc... just to get an idea of a kind of "rule"...

and you could import MIDI files...

i am splitting the sprites via DLI... of course in a "zone" you can set 4 sprites in 1 DLI... but you have to "reject" other sprites which could not be mapped to the 4 available hardwaresprites in a zone as they would overlap... the ringbuffer from MSX is dealing with the available 32 hardwaresprites so no sorting etc needed here as the TI chip is capable of displaying 32 sprites but only restriction not more than 4 per scanline... not sure how this logic can be implemented into "my" method which is based on sorting the 16 virtual sprites by y-position and then map them to the available hardware sprites.... the mapper is setting on determined positions DLIs where the engine thinks would be the optimal way... (in general the place where no sprites are overlapping and a "new" zone could start). the not capable sprites are moved off the screen and are not treated by any engine...

ok. played around with the code of multiplex. i found several bugs which are removed and tried to implement the ring buffer kind of concept but this does not work... my feeling tells me that there is a logical problem.... my question is... after sorting all sprites depending on their y-position how should i fill the buffer for flickering? i mapp the first 4 sprites to the players and set a DLI for this zone... the next sprites from no. 5ff are tested if they overlap with sprite 4...if so they are rejected and the next possible sprite starts the next zone with 4 hardwaresprites and so on... in the demos you see the white scanlines which indicate a starting zone... so in theory i would need a buffer for each zone??? containing all sprites which would be there even the rejected ones? i am not sure if i can virtually flipp through the whole 16 sprites with the ring buffer concept?

ehmmm... just zip it?

ehmmm.... we are talking here about a machine build 1979... so let's call it simply whatever you want... i am not a tech guy... so appologise. here is the reference... http://shit.sclassic.net/index.php/TMS9918

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?

i mean multiplexing & ring buffering on c64?

http://www.atariage.com/forums/index.php?s...pic=66811&st=25 what do you think? am i wrong? and why should this method not be possible on c64?

ok. here are my thoughts about sprite flickering & ring buffer: assuming we have 8 virtual sprites no. 1-8 and our engine is trying to assign them to the 4 available hardware players per scanline... i am not going into the sorting issue (which makes life really easier...please read the other docs here...) no... let's think about they are all have y-position f.e. 100... so they stay on one line... 1st frame: 1,2,3,4,[5],[6],[7],[8] sprites 1-4 could be mapped on the 4 hardware sprites. the engine markes sprites 5-8 as "non-mapable"... now think on ms pacman and on joust. there the engine is "flickering" through the virtual sprites... now the ringbuffer used in MSX games by konami comes in place. the video chip can display 4 sprites max. per scanline as well... so let's see how this works in the 2nd frame... assuming that the sprites haven't moved... so... the starting point in the virtual sprite list is incremented by 4 (the max. available hardware sprites...) so... we start with sprites 5,6,7,8,1,2,3,4 now... the mapper rejects sprites 1,2,3,4 2nd frame [1],[2],[3],[4],5,6,7,8 so... the other sprites are visible... hope this makes it clear... here is another example with 6 sprites on one scanline... 1st frame 1,2,3,4,[5],[6] 2nd frame 1,2,[3],[4],5,6 3rd frame [1],[2],3,4,5,6 4th frame 1,2,3,4,[5],[6] ... hope you got it...so on weekend i try to implement this ringbuffer into my sprite engine...

and here is another old discussion: http://www.atariage.com/forums/index.php?s...&hl=multiplexor

could simply because segments have to be specified by $ff,$ff,start adr lo, start adr hi, end adr-1 lo, end adr-1 hi. maybe the $ff,$ff dos header is missing...

my thoughts were kind of data structure which specifies the enemy, it's position etc and another engine is handling the movement & action... triggering will be done by position of the scroll-window... but not sure if this is ok...

and the original rent... http://www.student.oulu.fi/~loorni/covert/rants/sprite.htm just to have all in one topic...

more than worth a read: http://www.student.oulu.fi/~loorni/covert/rants/sorting.htm speculative sprite sorting methods...

just to let you know what i am doing at the moment... well...to be honest...i am playing most of the time world of warcraft... but there are small boinxx progresses still going on... i am playing around with the enemy engine (how should it be implemented) but i never made such a thing... maybe TMR can help here how he made a kind of pattern based enemy routines in his shoot'em ups? i am still playing around with concepts before i touch code again.... so don't worry...boinxx is still growing but i do not post any new binary yet.

this pic is very cool enhanced...

the instruments are cool... and the deep purple riff was a nice suprise...

what do you need for instruction for flashpack? as far as i remember our packer is in english already? the only issue with flashpack is that it just can handle one segment not multi segments like superpacker... or do you mean how you can depack it on your own?

but joyride has a multiplexor as well... emkay. but do not understimate that in demos you have a predefined environment with precalculated conditions... in a game your engine needs more flexibility and i can not say that there is just a small step from a demo to game engine... but f.e. the unity one... the sprites could be all enemies in a shoot em up like uridium or delta f.e.... if you choose your enemy patterns well than you can avoid conflicts... but as i mentioned... it depends on the game...

i think you mean this part?

yup. indead. ms pacman seems similar engine like joust... have to look more into it... i have to switch the cutom font off to see if the eyes of the ghosts are made by chars and just the ghosts are PMs.

it seems that you are right... ms pacman seems to work in same way. i must check beef drop homebrew... if it use a similar technique than the programmer is alive so we can ask him how it works in detail... btw. does not use most of the 2600 games this kind of logic???