ENTERPRISE KLUB
2019. május 25., 1055 Budapest, Nyugati tér 9. 14-19 óráig
Részletek
Welcome, Guest. Please login or register.


Author Topic: Video config that allows to draw sprites vertically (Read 2440 times)

Offline ssr86

  • EP user
  • *
  • Posts: 359
  • Country: pl
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 40.0 Firefox 40.0
    • View Profile
Video config that allows to draw sprites vertically
« on: 2015.August.24. 22:15:29 »
Just had an Idea...
On the Enterprise you could actually setup the lpt so that going one screen line up/down would become just a simple dec/inc of the high byte of screen address (and going one pixel left or right would be dec/inc of the lower byte). There would be some additional memory costs (as you see below - lines have to be 128 bytes long)... but you could use it for scroll buffer or just as a somewhat complicated (beacuse not linear) buffer for other things I guess.

The idea is:
- have 2 screen buffers
- have separate modeline for each screenline
- 1st buffer lines start at xx00
- 2nd buffer lines start at xx80

This way changing screen equals toggling the 7th bit of the lower byte of each line address.
If you don't do scrolling then there's quite a waste of memory...I guess...
Also the "seperate modeline" bit can be limiting, but with the 160x144 resolution it's what you need to do anyways...

Drawing sprites vertically (as opposed to standard horizontal drawing - left to right or right to left) allows simple (and quick) horizontal clipping of compiled sprites. Which I personally find problematic for non-standard sprites and horizontal cipping seems to be the more used type of clipping that you have to do in games (at least horizontal scrolling ones which are the majority I think).

Don't know what would be the other advances of this...
« Last Edit: 2015.August.25. 21:56:07 by szipucsu, Reason: Slight modification in the topic title as suggested »

Offline geco

  • EP addict
  • *
  • Posts: 5334
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 40.0 Firefox 40.0
    • View Profile
Re: Video config that allows to draw sprites vertically
« Reply #1 on: 2015.August.25. 08:58:16 »
I use it for the game under work, because it draw the objects vertically, screen size is 92x112 pixels (256 col mode), very good, because of fast vertical movement during drawing, 1st video screen starts at xx00h, the 2nd starts at xx60h, xxc0h-xxffh are used for other data in the 1st video page, so the bigger waste is on the 2nd video screen from xx5dh-xx5fh and xxbdh-xxffh. The best would be to arrange the sprites also with this solution, so add hl,de could be avoided, I will try to do it also to get small additional speed, and I using port 82h to change between the 2 screens.
« Last Edit: 2015.August.25. 21:56:44 by szipucsu, Reason: Slight modification in the topic title as suggested »

Offline ssr86

  • EP user
  • *
  • Posts: 359
  • Country: pl
  • OS:
  • Windows NT 6.2 Windows NT 6.2
  • Browser:
  • Firefox 40.0 Firefox 40.0
    • View Profile
Re: Video config that allows to draw sprites vertically
« Reply #2 on: 2015.August.26. 20:40:17 »
I have to ask - what kind of game is it?:).

Quote
The best would be to arrange the sprites also with this solution, so add hl,de could be avoided, I will try to do it also to get small additional speed, and I using port 82h to change between the 2 screens.
By "using port 82h" you mean having two lpts and toggle them by changing the nick's lpt address?
This however is an option only for non-scrolling screen, right? I mean - because of having a seperat modeline for each line of display.

As for the sprites - I wonder what the gain would be...
- when calculating the start address of where the sprite should be drawn. You just need to load the address with more-or-less the x and y coordinates of the sprite.
- when moving up/down a screen line - inc h instead of add hl,de or (when de not preloaded or not constant - for example for compiled sprites) ld de,xxxx; add hl,de. The increment should be at least 3 times faster then the add...

Oh, and you only need to use the 8 bit inc/dec.

But I don't think that storing sprite in similar way would give any benefits (which "add hl,de" did you mean?) over having them in linear buffer. Well maybe if you do flipping - then you don't have to do the add/sub to go from sprite's line end to beginning. Or maybe having the buffer for erasing sprite stored in this way would be more benficial...

Would be fun to try...
« Last Edit: 2015.September.13. 11:18:11 by ssr86 »

Offline geco

  • EP addict
  • *
  • Posts: 5334
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 38.0 Firefox 38.0
    • View Profile
Re: Video config that allows to draw sprites vertically
« Reply #3 on: 2015.August.27. 08:44:55 »
I have to ask - what kind of game is it?:).
It is a 3d game, I started to convert a CPC preview, and during conversion I got some idea, and made a lot of modifications. :)

By "using port 82h" you mean having two lpts and toggle them by changing the nick's lpt address?
This however is an option only for non-scrolling screen, right? I mean - because of having a seperat modeline for each line of display.

As for the sprites - I wonder what the gain would be...
- when calculating the start address of where the sprite should be drawn. You just need to load the address with more-or-less the x and y coordinates of the sprite.
- when moving up/down a screen line - inc h instead of add hl,de or (when de not preloaded or not constant - for example for compiled sprites) ld de,xxxx; add hl,de. The increment should be at least 3 times faster then the add...

But I don't think that storing sprite in similar way would give any benefits (which "add hl,de" did you mean?) over having them in linear buffer. Well maybe if you do flipping - then you don't have to do the add/sub to go from sprite's line end to beginning. Or maybe having the buffer for erasing sprite stored in this way would be more benficial...

Would be fun to try...
Yes, 2 LPT's are used, and it is non scrolling, but it can be used for scrolling game also, in this case you have to change only one byte/LPB and it has to be done only on the inactive LPT, so it should be faster, and using more memory :)
Sorry for the sprite add hl,de is valid for my case only, if drawing the sprite do not starts the beginning i have to jump to the next sprite line to the same position, this is the reason why it makes sense :)

Offline ssr86

  • EP user
  • *
  • Posts: 359
  • Country: pl
  • OS:
  • Windows NT 6.2 Windows NT 6.2
  • Browser:
  • Firefox 40.0 Firefox 40.0
    • View Profile
Re: Video config that allows to draw sprites vertically
« Reply #4 on: 2015.August.27. 21:07:07 »
Another observation:

If line width is less or equal $55 (85 bytes) then you can triple buffer. The "free" area in each 256bytes could be used to store a "clean" copy of the background. Then ther'd no need to save the sprite's background for erasing. Although one still would have to erase it but by using the 3rd buffer. So also no need for having two background buffers for each object. In 256 colors the drawing and erasing routines should be the same and only differ in the src/dest addresses (or so I think).

Offline geco

  • EP addict
  • *
  • Posts: 5334
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 38.0 Firefox 38.0
    • View Profile
Re: Video config that allows to draw sprites vertically
« Reply #5 on: 2015.August.28. 10:08:22 »
Another observation:

If line width is less or equal $55 (85 bytes) then you can triple buffer. The "free" area in each 256bytes could be used to store a "clean" copy of the background. Then ther'd no need to save the sprite's background for erasing. Although one still would have to erase it but by using the 3rd buffer. So also no need for having two background buffers for each object. In 256 colors the drawing and erasing routines should be the same and only differ in the src/dest addresses (or so I think).
In my case it is not necessary, I do not have to save the background, because 1st the background is drawn and after the sprites are drawn to the screen in each phase, but it is a good idea for other cases where the whole background is not changing only the sprites should be drawn, and it is much faster than the save background, and restore background solution, and as I imagine, the drawing / erasing routines can be the same as you mentioned :)
If i remember well I used similar thing in Exploding Fist conversion.

Offline ssr86

  • EP user
  • *
  • Posts: 359
  • Country: pl
  • OS:
  • Windows NT 6.2 Windows NT 6.2
  • Browser:
  • Chrome 46.0.2490.80 Chrome 46.0.2490.80
    • View Profile
Re: Video config that allows to draw sprites vertically
« Reply #6 on: 2015.November.17. 23:26:11 »
I've finally decided to try it out. Hope you like it ;P

However for now only flipping and animation. He runs and jumps. The video memory is setup to use two screens + a clean buffer however at the moment the second screen is unused... The current code uses standard sprites so it could be faster.

I use sprites stored rotated clockwise by 90 degress and in a zig-zag way, I mean the odd lines are normal and the even are inverted. This allowed for some optimization however when it came to do the clipping it became a problem... So maybe I should change it... Also the draw and erase routine could not be one and the same.
Flipping has no additional cost. The same will be true for compiled sprites - that's because we draw the sprite in vertical stripes so we just draw the stripes starting from the right screen side (leftmost stripe goes to the rightmost sprite screen position etc). Horizontal clipping of compiled sprites should also be easy, because it becomes the same as vertical clipping of normally drawn sprites - a "simple" reordering of lines (not very expensive - could be done so that drawing each line is a seperate subroutine so then the cost is the cost of call+ret times the height... )

The screen is not tiled.. it's a bitmap... I know I should write a tile system for this... maybe I'll try someday as well as scrolling. Or someone else would want to try? ;)
The current source is in the zip archive. It shows a basic "template" I am currenyly using. However the loader file is messy as it's not used for now (nothing to load yet) so I didn't clean it...
Does it fulfill the requirements about the exos compatibility, opcodes etc.?
« Last Edit: 2015.November.18. 16:04:37 by ssr86 »

Offline geco

  • EP addict
  • *
  • Posts: 5334
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 38.0 Firefox 38.0
    • View Profile
Re: Video config that allows to draw sprites vertically
« Reply #7 on: 2015.November.18. 08:49:28 »
Hey, it's looking cool :)

Offline ssr86

  • EP user
  • *
  • Posts: 359
  • Country: pl
  • OS:
  • Windows NT 6.2 Windows NT 6.2
  • Browser:
  • Chrome 46.0.2490.80 Chrome 46.0.2490.80
    • View Profile
Re: Video config that allows to draw sprites vertically
« Reply #8 on: 2015.November.19. 19:03:23 »
It seems that I could do the erasing together with drawing in one routine. The catch is that my sprite would need some additional "clean" lines (as much as the max step in its movement is to be). It wouldn't make it quicker to draw and erase the sprite BUT I wouldn't need to double buffer because in this way there would be no flicker or tearing (but correct me if I'm wrong).

Also I should quit the "zig-zag" drawing because it's not much more expensive to get back up to draw only up-down stripes...
« Last Edit: 2015.November.19. 19:27:21 by ssr86 »

Offline ssr86

  • EP user
  • *
  • Posts: 359
  • Country: pl
  • OS:
  • Windows NT 6.2 Windows NT 6.2
  • Browser:
  • Chrome 46.0.2490.86 Chrome 46.0.2490.86
    • View Profile
Re: Video config that allows to draw sprites vertically
« Reply #9 on: 2015.November.21. 14:05:14 »
It wouldn't make it quicker to draw and erase the sprite BUT I wouldn't need to double buffer because in this way there would be no flicker or tearing (but correct me if I'm wrong).
Forgot what would happen if there are more sprites and they would overlap - one would erase the other, so it's no good... But should check...maybe If you skip "erasing" the transparent bytes, it wouldn't be an issue...
« Last Edit: 2015.November.21. 15:32:01 by ssr86 »