PVR Spritesheets Turorial

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
dcTom
DCEmu Junior
DCEmu Junior
Posts: 43
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Mon Feb 20, 2017 7:49 pm
Has thanked: 0
Been thanked: 0

PVR Spritesheets Turorial

Post by dcTom »

First of all thanx for this great turorial, it works fine.

on Debian 11 qt5-default doesnt exist any more, i dont know i there is any better solution,
but to fix it i did the following steps
1.

Code: Select all

sudo apt-get install equivs
2.

Code: Select all

cat <<EOF > qt5-default-control
Package: qt5-default
Source: qtbase-opensource-src
Version: 5.99.99+fake-13ubuntu37
Architecture: all
Depends: qtbase5-dev, qtchooser
Suggests: qt5-qmake, qtbase5-dev-tools
Conflicts: qt4-default
Section: libdevel
Priority: optional
Homepage: http://qt-project.org/
Description: Qt 5 development defaults fake package
EOF
3.

Code: Select all

equivs-build qt5-default-control
source
https://www.projectguideline.com/faking ... tion-tool/


but how do i rotate objects with the PVR API is ther any documantation ?
User avatar
ThePerfectK
Insane DCEmu
Insane DCEmu
Posts: 147
Joined: Thu Apr 27, 2006 10:15 am
Has thanked: 27 times
Been thanked: 35 times

Re: PVR Spritesheets Turorial

Post by ThePerfectK »

What do you mean by "rotate objects"? Do you mean, rotate the texture on the polygon you are drawing, or do you mean rotate the entire polygon? Both are done in the draw_sprite() function according to the tutorial. A polygon is defined as two vertices in the example: float x0, float y0, float x1, float y1. These 4 values represent the two corners of the polygon, xy0 is the top left corner, and xy1 is the bottom right corner. These are the on-screen positions where the corners lie.

To rotate the polygon, you need to do some trig on these vertices to rotate them around an origin. The appropriate way to do this is to pack a matrix with the correct values, then use the dreamcast's built in sh4 math functions to perform fast math on the vertices that way, but that's way beyond this quick post. A simpler solution is to calculate out the resultant location of those 2 vertices with simple one-line formulas derived from our matrices math in the first place.

To rotate a point in space, you calculate out the x' and y' positions for each vertex by using their original x and y values. By "original x and y values" I mean the values that they resided in when they formed a square polygon before any rotation, so their original values are as follows:

Code: Select all

float x0 = x;
float y0 = y;
float x1 = x + sprite->width;
float y1 = y + sprite->height;
where "x" and "y" are the offset for the sprite, and x + width and y + height are the bottom corner of the sprite plus the offset on screen. The formula to rotate is as follows:

Code: Select all

x0' = cos(angle)*x0 - sin(angle)*y0
y0' = sin(angle)*x0 + cos(angle)*y0

x1' = cos(angle)*x1 - sin(angle)*y1
y1' = sin(angle)*x1 + cos(angle)*y1
Note that angle here is in radians, not degrees. To get the angle in radians, you multiply your angle in degrees by pi/180. The above four formulas will transform your xy0 into xy0' and xy1 into xy1', which is the final screen position where they should reside to represent that polygon rotated by your angle in radians on screen.

This rotates the polygon physically on screen, but if you want the polygon to remain stationary and merely rotate the texture mapping of the polygon, the process is much the same except instead of manipulating xy0 and xy1 which are the vertices, you manipulate uv0 and uv1, which are the texture mapping coordinates. These coordinates map to points on on the texture which the PVR will sample from when filling the polygon. Unlike xy0 and xy1, these are not absolute screen coordinates, they instead represent coordinates as percentages of the texture. I.e. instead of saying that the top left corner of your polygon maps to an arbitrary position 10 texels right and 10 texels down in your 100x100 texture, you instead say your top left corner of your polygon maps to 10% right and 10% down in your 100x100 texture, meaning you divide your texel position by the texture width/height and multiply to get the percentage. UV mapping uses percentages of textures for its coordinate system instead of absolute texel positions, because things like mipmaps exist where you will switch between textures of different sizes that are pre-scaled as a performance optimization, and you want to make sure you're sampling the same part of the texture regardless of the mipmap size.

To rotate the uv coordinates, just use the same rotation formulas from above.
Still Thinking!~~
dcTom
DCEmu Junior
DCEmu Junior
Posts: 43
Joined: Mon Feb 20, 2017 7:49 pm
Has thanked: 0
Been thanked: 0

Re: PVR Spritesheets Turorial

Post by dcTom »

thanks for the help.

i was looking for somthing like glrotate() and was hoping that there is somthing simular.

rotating is now working fine,
i made the sin and cos calculation not for x0,x1,y0 and y1

insted i made it for all 4 vertexpoints of the poligon.

is there a possibility to rotate or scale the complete screen. my game is running on tate mode so its vertical,
it is a lot of calculation to rotate and scale every singel object on screen.
so is there a possibility to rotate the complete szene?
User avatar
ThePerfectK
Insane DCEmu
Insane DCEmu
Posts: 147
Joined: Thu Apr 27, 2006 10:15 am
Has thanked: 27 times
Been thanked: 35 times

Re: PVR Spritesheets Turorial

Post by ThePerfectK »

You can render to a framebuffer texture, then rotate the texture, which would rotate the entire screen, but be aware that rendering to a framebuffer on the dreamcast consumes an entire vsync cycle. This is because you command the PVR to draw to the texture, and the PVR draws at vsync completion, so you'll be drawing to texture one frame, then drawing the texture to the screen the second. This means you'll be limited to 30 frames per second instead of 60.

That said, the correct way to handle all this is to use the dreamcast's sh4 math calls to perform all your calculations in one single matrix transformation per vertex. You can shift the x, y, and z component of your vertex all at the same time with 128-bit SIMD instructions. Using matrices math, you can pack not only your rotation, but also translation into each polygon, so the calculations you're already doing to move the polygons around can also handle the rotation at the same time. You'll need a primer in linear algebra to tackle that first.
Still Thinking!~~
dcTom
DCEmu Junior
DCEmu Junior
Posts: 43
Joined: Mon Feb 20, 2017 7:49 pm
Has thanked: 0
Been thanked: 0

Re: PVR Spritesheets Turorial

Post by dcTom »

are the sh4 math calls
somthin different than the math library from

#include<math.h>

i saw that there is also a

#include <dc/fmath_base.h>

in the coments of the Spritsheet code is
written for large batch of sprites its better to use the SH4's "store queues" insted of pvr_prim.
is ther any example for the store queues?


the reason i ask is that i made a test how much sprite i can draw on screen and im a little bit confused,
with an older 2D engine i wrote with KGL the framrate droped from 60 to 30 fps around 700 sprites on screen and with around 1400 sprites to 15 fps
now the framerate droped already with 400 sprites to 30fps but around 1500 sprites i still have around 30 fps

also the there is nearly no performance differnce between sprite mode and poligon mode
dcTom
DCEmu Junior
DCEmu Junior
Posts: 43
Joined: Mon Feb 20, 2017 7:49 pm
Has thanked: 0
Been thanked: 0

Re: PVR Spritesheets Turorial

Post by dcTom »

the stuff is running now in dma, polygon and sprite mode.

i found out that the performance depends on the size of the objects and not the amount of objects
dcTom
DCEmu Junior
DCEmu Junior
Posts: 43
Joined: Mon Feb 20, 2017 7:49 pm
Has thanked: 0
Been thanked: 0

Re: PVR Spritesheets Turorial

Post by dcTom »

i was trying to use sound (Wav + OGG) files inside the spritesheet tutorial,
but got an runtime error

sndoggvorbis: couldn't open source file

the file is inside the romdisk folder and i think perhaps this is the problem.
because i think the romdisk.img is not created from the romdisk folder
the source of the textures are comming from the assets folder.

so how i have to change the makefile to find the .ogg and wav files
Post Reply