Developing my new game for the scene!

Pagina 2/75
1 | | 3 | 4 | 5 | 6 | 7

Van hit9918

Prophet (2899)

afbeelding van hit9918

02-12-2013, 00:17

The massive screen 8 DMA makes no difference to screen 5 DMA Tongue
Because screen 8 uses 16bit acess (double banked). But screen 5 doesn't, so there is no additional DMA left for the rest.

And I think the LMMM, the logic commands, go same speed, same pixels per second, on all screens.

So when you make a software sprite with LMMM same speed and the restore with HMMM which on screen 5 goes double speed, then as a whole you get this "screen 8 doesnt take twice the time".

Van hit9918

Prophet (2899)

afbeelding van hit9918

02-12-2013, 00:24

Fastest software sprite is the transparent things done by cpu writing spans
and blitter do cleanup copies in parallel.

An easier way to speed up LMMM is using LMMC, feeding source with the cpu from RAM.
I think it was said there is no command where the outi is too fast.

Van flyguille

Prophet (3028)

afbeelding van flyguille

02-12-2013, 00:33

hit9918 wrote:

The massive screen 8 DMA makes no difference to screen 5 DMA Tongue
Because screen 8 uses 16bit acess (double banked). But screen 5 doesn't, so there is no additional DMA left for the rest.

And I think the LMMM, the logic commands, go same speed, same pixels per second, on all screens.

So when you make a software sprite with LMMM same speed and the restore with HMMM which on screen 5 goes double speed, then as a whole you get this "screen 8 doesnt take twice the time".

I am not planning to use LMMM, because I am not planning to use software sprites (so far), what I means, with animated tiles, is 16x16 tiles that as a whole change its graphics each frame, to animate fire, wather running, clouds, things like that. If the map is rendered in a claver way, you can control what tiles is being active for animations at a given time.

So, always I am comparing BYTE move in screen 5 with Byte move in screen 8.

Van hit9918

Prophet (2899)

afbeelding van hit9918

02-12-2013, 00:42

@flyguille,
"ARTRAG, nice, but scrolling is not all the job."

With 9938 horizontal scroll, scrolling is really all the job Smile
The blitter cant be used for anything else.
Not only timing wise, but both buffers locked by the permanent copy work.

"what I means, with animated tiles, is 16x16 tiles that as a whole change its graphics each frame, to animate fire, wather running, clouds, things like that"

Sounds like a candidate for ARTRAGs scroller that did involve tile animation into said blitterscroll.

Van flyguille

Prophet (3028)

afbeelding van flyguille

02-12-2013, 00:54

hit9918 wrote:

@flyguille,
"ARTRAG, nice, but scrolling is not all the job."

With 9938 horizontal scroll, scrolling is really all the job Smile
The blitter cant be used for anything else.
Not only timing wise, but both buffers locked by the permanent copy work.

"what I means, with animated tiles, is 16x16 tiles that as a whole change its graphics each frame, to animate fire, wather running, clouds, things like that"

Sounds like a candidate for ARTRAGs scroller that did involve tile animation into said blitterscroll.

Who says 9938, I already did a source for 9958, but for 8x8 metatiling, now I am moving on 16x16

scrolling is just rendering only two rows or columns per EACH two frames, because as it uses byte moves, it rendes only one time per two frame, but with the vdp registers you can move one pixel per frame.

That results in a lot of free time, for copying entire tiles, in why to do animations.

After that, If I would do part of the sprites rendered by soft, or I would do all with vdp sprites, and cleverly settings its vertical position, that is another thing that until now I didn't take, there is a third option, that is when the character is far from you it is just a tile draw, when it comes in action, it swhitch to vdp sprite.

Van hit9918

Prophet (2899)

afbeelding van hit9918

02-12-2013, 01:01

Oh, first time the topic 9958 plus blitter action, nice!
Unlike 9938 horizontal scroll, blitter needs not always touch the whole screen, animations can have much higher fps.

Van hit9918

Prophet (2899)

afbeelding van hit9918

02-12-2013, 01:27

You get most action when you manage to decouple the blitter action from scroll and sprites.
I.e. only blitter action may loose framerate, but not the rest.
This would allow perverse amounts of animation or software sprite masses Smile

Van flyguille

Prophet (3028)

afbeelding van flyguille

02-12-2013, 01:39

it is easy to dissacouple, when scrolling the render routine already reads the metatile attributes, the code only needs to maintain in an array, which special attrib is, to which X/Y is the tile in the screen, if by scrolling the X/Y gets out of the view, the routine needs to FREE that element from the array, we talks about an array like 20 elements in size, not big than that, so, to have all X/Y updates is fast, the array must track as the X/Y the tile number and special attribute (all coded togheter as a 16 bits number, just readed from the map),

So if certain code is meant to say, hey, switch this tile graphic with the tile+1 graphics on even frame, a VDP command is issued. And that metatile gets done.

When creating the map, you just don't setup too much special effect togheter.

Van PingPong

Prophet (3680)

afbeelding van PingPong

03-12-2013, 07:46

flyguille wrote:

Those vdp commands during displayed bitmap lines, it is a lot slow more than the 50%.

NO! Speed (byte copy) IS the SAME on all bitmap modes. It's the amount of data you move that is doubled, so you get 50% of performances.
The vdp is not able to get advantage of the less bandwith in screen 5 to increase command speed, nor is slowed down by the screen 8 in command execution speed. the bandwidth allocated for commands is fixed and allocated in the SAME manner in all modes.
I suggest you to learn _Wouter docs about VDP VRAM timing and command speed.

Van flyguille

Prophet (3028)

afbeelding van flyguille

02-03-2015, 21:33

VIDEO: well, guys, I am presenting, a little advance of my new game....

new game demostration video

engine specs:

Now, the game engine is complete, Stress test with up to 12 or 13 characters walking around.

SCREEN 8
double buffer (for avoiding sprite flickering)
any way scrollable (not only rigid 8 ways, but any way 360º angle).
Software sprite engine, it holds a cache for sprite patterns in VRAM.
The map is bigger as 16 screens width, and 9 & half screens vertically.

Patterns in the background can be animated, like lava fluid running, water running, etc.

patterns can have 256 colors per pixels.
Sprites can have 255 colors per pixels.

ah, engine support multiplayer, up to 3 players.

how will looks like our hero ... it is a secret!... :D

Pagina 2/75
1 | | 3 | 4 | 5 | 6 | 7