Hardwarescrolling Control3.5a extension

[freddex73]

wow! I works perfectly with my code!

Wondering about another thing? that's an idea i have

I have an assambler Code for playing soundtracker music(MOD) for STE (By Paulo Simoes)

The idea is to load the code and module, then it writes the modulemusic into a memorybank (sampled in 12,5Khz or 25Khz) instead of playing the music.

So you can play the module as one Big DMA sample in STOS from the memorybank.. With zero CPU time!

Of course, it may be a good idea to shorten the number of tracks in the Module, so the sample will not be too big!

MODrout.zip

[thomas3]

That's awesome!! But how are you drawing your tiles? I figured I'd have to make another routine for that . If you want, send me your code for tile drawing and I'll write in in ASM for you .

I plan to do something with this too soon. Oh - one thing I forgot - make sure you call the background draw function for every sprite BEFORE you call the sprite draw function, and make sure you do it in the opposite order. In other words, say you have five sprites, your inner loop needs to work like this:

For I=1 to 5
Set current sprite as I (using a pointer to the right array)
Call background redraw function


For I=5 to 1
Set current sprite as I
Call sprite draw/background save function

Wait vbl
Call hardscroll function
Swap screens

Loop!

This makes sense if you think about it...!

As for the mod question... Dude, I know nothing about DMA or playing mods. But there are people here who do. Try one of the other forums!

[ljbk]

Hello !

Sorry but i have no time for Atari ST stuff.
I have not touched any ST code for about 5 years.

Paulo.

[joska]

I have an assambler Code for playing soundtracker music(MOD) for STE (By Paulo Simoes)

The idea is to load the code and module, then it writes the modulemusic into a memorybank (sampled in 12,5Khz or 25Khz) instead of playing the music.

So you can play the module as one Big DMA sample in STOS from the memorybank.. With zero CPU time!

I'm not sure if this can be done with that routine. I have been playing around with this routine myself and it use the volume registers in addition to adjusting the samples. So if you generate one big sample volumes will not be correct when you play it back. You would have to generate a table with volumes too and change it dynamically during sample playback from the 200Hz timer.

There are other MOD playback routines that does not use the volume settings, they are probably better suited for this project. Also, I suggest you generate individual samples for each pattern, that should save a lot of memory as patterns are usually played multiple times in a song.

[thomas3]

This sounds like another interesting problem to solve. What do you recommend as a MOD player that might fit this application?

[joska]

Maybe the original Lance Protracker replay routine can be used as basis? Remove/disable the code that controls DMA playback, and move the "DMA buffer" address each time you call the player to create a continuous sample.

[freddex73]

Hi, Thomas!
I use Control Extensions command to draw the blocks on screen.
Yes! you will get the code, I´ll just need to clean the code first.. then I´ll put it up here!

It had been a dream if it could be done!! ( Make a samplebank of a Moduletrack)
Love the soundtracker music, but it takes to mutch CPU time..

[thomas3]

Maybe the original Lance Protracker replay routine can be used as basis? Remove/disable the code that controls DMA playback, and move the "DMA buffer" address each time you call the player to create a continuous sample.

Cool. This sounds ^3 times easier than I was anticipating .

Now watch as it makes STOS explode....!!

[joska]

It's more complicated than that, this will only create one big sample. What if the song loops? You need to handle those sort of things. It would be better to study the sources of the player and modify it so you can "play" only selected patterns. Then create one sample per pattern, and play them in sequence according to the pattern table in the mod.

[freddex73]

'Yes, Joska!

Though, you can modify the module first in a Tracker.
But in the long run it would be great if you could "unpack" differents tracks, from the same Module file.

[joska]

To be really usable I think you must be able to create each track only once. The Lance player use ~30% CPU on an STE. Creating a 3 minute stereo sample would take one minute, creating a 25000*2*60*3 = 9Mb sample. Even in mono (not sure if the Lance player can do that, but you could probably mix the channels yourself which would use more time) at 12.5kHz you would end up with 750kB of samples per minute.

[metalages]

I think it is easier to use wizzcat Ste protrack routine in this case, set it at 12.5khz and modify the mixing routine which is quite simple to get mono directly instead of stereo. Probably more efficient and lot simpler than Lance routine for that. Also as Lance routine uses microwire would be more complicated to replay.

In my BLITSnd routine (http://www.atari-forum.com/viewtopic.ph ... 7&start=25) I have implemented an asyncupdate routine to be able to mix full update and precomputed replay for critical parts... But as it runs at 100kb/sec, the idea is probably to precompute MOD pattern one by one...

[metalages]

(if I well remember playing at 12.5khz with Wizzcat routine should be around 25% CPU)

[thomas3]

But also...
Are you aiming for the game to be running in 50Hz?
Could we just use a standard MOD player and instead concentrate on super optimising the gfx routs?
As this is a STOS project, running at 25 fps would still be impressive...

[freddex73]

Thomas,
Yes!! Im aiming for 50Hz

But of course is 25Hz good too!

Here you have a video with your STE Hardware scrolling routine!

https://youtu.be/WprhxDjco4U


Regards Fredrik

[thomas3]

That is looking awesome! Congrats!

Is the blue raster showing tile redraw? And is this compiled yet?

[mlynn1974]

Hi freddex73,
The hardware scrolling effect looks amazing in your demo. It's smoother than the Violent Death game Colin wrote with the Missing Link (STFM - no hardware scrolling). I wasn't aware of the Hardware Scrolling Control 3.5a extension. I think it's probably best to use Thomas's playfield system if you can't get a registered version to compile your program.

Hardware scrolling with minimal redraw is a very good way to implement this, but I'm not sure how you manage the wraparound at the end of the virtual screen without it pinging back or having to redraw large areas of the screen. How much CPU time does it take to redraw the tiles?

[thomas3]

Hey Michael,
I don't know if freddex did it this way, but one way to achieve an endless scroll effect is to draw your next row or column of tiles twice - once on the area that is about to be made visible, and once on the opposite side of the screen (e.g. at 320 pixels and -16 pixels if horizontally scrolling, relative to your display window). This then builds a duplicate screen behind where you've just scrolled from, which you can flip back to when at the end of your buffer. This means you can have a relatively small playfield.

Another option is to not do it with a playfield at all - dml talks about this in the agt threads. A 320x400 buffer would allow you 200 screen width scrolling if just adding to the logbase and redrawing your margins each time. This is then harder to manage multidirectional scrolling within versus a playfield. But you could do it on the stf, unlike playfield, and if you used sync scroll then performance would be v good.

[freddex73]

The Registered version of CONTROL3.2 extensions.

CONTROL32.zip

[freddex73]

Hi, mlynn1974!

It uses maybe 10% (Draws 1,5 x 2 pcs 16x16 blocks each VBL),
but Thomas is working on a faster routine for drawing blocks.


I have 960pix x 256pix area. I draw 1,5 blocks ahead (16x16pix) per VBL.

There are 16 x 60 blocks = 960 blocks total.

So, 640 VBL x 1,5 blocks ahead = 960 blocks
( you move the window 640 pix, then go back and start all over.. )

Don't know if this makes sense?

[joska]

I think it is easier to use wizzcat Ste protrack routine in this case, set it at 12.5khz and modify the mixing routine which is quite simple to get mono directly instead of stereo. Probably more efficient and lot simpler than Lance routine for that. Also as Lance routine uses microwire would be more complicated to replay.

Quite possibly, I have only played with the version from Paoulo and had the impression that the original player did not use the LMC.

[metalages]

I think it is easier to use wizzcat Ste protrack routine in this case, set it at 12.5khz and modify the mixing routine which is quite simple to get mono directly instead of stereo. Probably more efficient and lot simpler than Lance routine for that. Also as Lance routine uses microwire would be more complicated to replay.

Quite possibly, I have only played with the version from Paoulo and had the impression that the original player did not use the LMC.

I think Lance version have also used LMC to speed up volume rendering.
Wizcat routine was simpler, but if the goal is to play mono at 12.5khz, it will be efficient enough while being easier to adapt (adapt directly the render loop instead of down sampling as a post pass)

[freddex73]

How is a module structured?
Thinking if you can program your own code to convert modules Tracks to samples?

Thought to do it in stos. Then maybe get help with ASM to speed up some things.

[metalages]

Basically you have a score interpreted at some point that tells the render part executed each frame what to do with the samples.
The concept is not complicated but .MOD manages a lot of different effects that apply on the rendering.
Managing all effects cases correctly needs work in my opinion.

Wizzcat routine is here (for example) :
https://github.com/ggnkua/Atari_ST_Sour ... .FLD/STE.S
To adapt rendering to mono you would have to merge the two rendering loops you can find by looking for "REPT LEN"
Then remove all the interupt stuffs and call the routine in loop / full time.

[MM41]

Really promising, good job Freddex73