Quote:

Yeah sure, but that C64 game was far more than 64 tiles I bet. Did you ever find out what would be the max? (combined with a complete game eh)

The largest I tested was 128*64, but that was 2 colors only so no update in the color table.. and that used a lot of CPU time. You may be able to precalc some of it and use copy commands to do the updates tho...

Quote:

Quote: What is this game ? It's only an experiment of 4pix scroll. not a game. 4pixels because with a little trick it's possibile to have 2 colors x 8pixels area even with scrolling.

You are talking abour H-scroll of 4 pixels?

yeah, I knows that trick, but that is LEVEL-MAPPING FREEDOM vs 2 colors per 8h-pix.

The trick is to do the MAP of the stage, in the way that two tiles nexts horizontaly has atleast ONE COLOR in COMMON. The problem of this, is that if you likes freedom for mapping, you finished doing GFX too dark/bright (where all GFX has a black/white/a given color Background).

if you use freedom of colors use, you needs to set restrictions on the mapping like, a given tile only can have at its left other one tile from certain group of tile... , so, maybe one can set up to 4 tile-groups of 32 tiles that makes 128 tiles, and the other 128 will be used for the +4pix scroll set.

as rule, you can setup that the group 1 only can have the group 4 at its right, and only the group 2 at its left.... and that way is possible to use more colorful stages with 4pix h scroll..

anyway, if talking about MSX2, don't mis that there is a lot of VRAM and you can change the PATTERN pointer table adress.-... so, writing 4 or 8 patter + color tables will be no problem.

Quote:

I can easily scroll a 256x128 pixels area (color+attributes) at 12.5fps. Limitations: you can have only 128 distinct patterns per frame on each of the two areas (top 64pixels and center 64pixels). You can change at maximum of 16 patterns at each 4x8 pixel scroll, by blitting from ram to vram so you do not need to upload all the tiles in an entire level to vram, you can change only the tiles that appear while scrolling. Because of the fps the perceived speed is about 50pixels/sec. the scroll appear quite smooth

Nice to hear! Hopefully this can be used for some game, Pac-Land for example!

Quote:

Quote: I can easily scroll a 256x128 pixels area (color+attributes) at 12.5fps. Limitations: you can have only 128 distinct patterns per frame on each of the two areas (top 64pixels and center 64pixels). You can change at maximum of 16 patterns at each 4x8 pixel scroll, by blitting from ram to vram so you do not need to upload all the tiles in an entire level to vram, you can change only the tiles that appear while scrolling. Because of the fps the perceived speed is about 50pixels/sec. the scroll appear quite smooth Nice to hear! Hopefully this can be used for some game, Pac-Land for example!

If i have time i will post some demo. CPU usage is quite low.

Quote:

anyway, if talking about MSX2, don't mis that there is a lot of VRAM and you can change the PATTERN pointer table adress.-... so, writing 4 or 8 patter + color tables will be no problem.

On msx2 is totally another story. I can use R18 and forget a little about colorclash....

I have to say, that VDP limits are partly reached already, because VDP limits are reached in programmers´ heads.

Please don´t get me wrong, I don´t mean to be offensive at all.

As same way as VDP has it´s limits, programmers have their limits too, they can be gurus what comes to art of programming, but they, like we all, can have limits in their imagination.


Sometimes it´s said, that "Sure, it can be done, but it takes so much CPU time, that it makes game unplayable".

I believe that.

But I have almost never heard anyone saying "Sure, it can be done, but as it takes so much CPU time, that it makes game unplayable, so why not use that routine(s) to make SUper-Animated-Never-Seen-Before-Titlescreen, as it doesn´t affect playability, if CPU usage is HIGH in TITLEscreen!"


I really like to see some never-seen-before effects used in titlescreen(s).

Or is there something that I (mere mortal, who don´t have too much knowledge about machine code and inner mind of VDP) don´t know, can such CPU melting routine(s) in titlescreen(s) affect in-game speed also?

The point with title screens is that they are just that: title screens. You can spend all your CPU time on that title screen, but for what? Typically screensplit effects (scrolling 'n stuff) usually look ugly on title screens. And the things that *are* possible - which will fit a title screen in a creative way - are not much CPU intensive in the first place.

Many movie 'title screens' are just white words on a black background, and those are movies with budgets to make any kind of title screens imaginable.

It's not a matter of whether you could, but whether you should.

As for CPU-intensive: sure I believe that. Especially updating whole screen 4 pages in one frame, full screen 5 smoothscroll or tricks that require screensplits and squeezing game code in between the interrupts will require a great deal of planning and reduce CPU time. But I don't think it is impossible: as already stated in this thread games such as Manbow2 and Bombaman use such techniques and I don't see why pre-calculated partial copying (enabling highspeed screen 5 smoothscroll) would be fundamentally different as soon as you have the precalculation model sorted out. It won't be easy, but somehow people here are more into designing new chips than fully squeezing the old ones

Screensplit effects in title screens? I could imagine colour gradients in order to surpass the 16 colour limit in screen 5; imagine a background sky, road or stretch of grass beautifully fading in twelve colours that are actually only one. Then again screen 8 would make a lot of that possible for still images already.

There is a hard limit you can't get around with fancy coding. And that is the VDP memory bandwith, wether it is from CPU <> VRAM or VRAM <> VRAM. There's been done calculations, in screen 5, at most you can copy per interrupt is 5KB. A fullsize Screen 5 is a little less than 16KB.

To give you an example, YsIII uses precalculated copying. The technique is called "Delta rendering". Render the deltas between each frame only. Play it and notice the scroll rate, some areas are acceptable, others go like a slideshow. Still, the makers achieved something impressive although they pretty much hit the roof as to what's possible.

Quote:

Screensplit effects in title screens? I could imagine colour gradients in order to surpass the 16 colour limit in screen 5; imagine a background sky, road or stretch of grass beautifully fading in twelve colours that are actually only one. Then again screen 8 would make a lot of that possible for still images already.

Apart from that, MäSäXi was referring to CPU-intensive never-seen effects.. and color-splits are common practice nor are they CPU-intensive.

The nice thing about coloursplits is that you hardly notice them if they're done in the right way so indeed I probably missed them if they are so common. Can you give some examples of where they're used?

Well, it should be less than 5K/frame

with 5K/frame you can have fine full screen horizontal scroll also in screen 8....

16*5K > 48K

This means that using set adjust register (16 positions) you have the time
to set up a new alternate hidden page (48K) ....

Yes, only if the entire screen is static, which for games it never is. Background scroll, foreground scroll and nonsprite objects moving leaves you in the cold quickly Nor would there be any visible changes for a timespan of 16 frames.

Quote:

The nice thing about coloursplits is that you hardly notice them if they're done in the right way so indeed I probably missed them if they are so common. Can you give some examples of where they're used?

They're 'common', but I dunno whether they are common in game title screens. They're common in demos tho, that makes them a common effect. It all depends on your title screen. If you only have a white word on a black background then you hardly need any color splits anyway. And that's my point exactly: the first priority is to make a title screen that fits the game, and whether that may be technically just simple to do shouldn't be relevant.

Quote:

"It won't be easy, but somehow people here are more into designing new chips than fully squeezing the old ones"

Maybe it could be easy ...
Imagine the bitmaps effects on Screen 5!

Quote:

"Well, it should be less than 5K/frame with 5K/frame you can have fine full screen horizontal scroll also in screen 8.... 16*5K > 48K This means that using set adjust register (16 positions) you have the time to set up a new alternate hidden page (48K) ...."

Well, what is if it should be around 5KB+ ... After all the estimations could be corrected.