2D graphics / KOS tutorials
-
- Mental DCEmu
- Posts: 415
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Thu Oct 10, 2002 7:18 pm
- Has thanked: 0
- Been thanked: 0
- Contact:
-
- DCEmu Ultra Poster
- Posts: 1754
- Joined: Wed Jul 17, 2002 11:25 am
- Has thanked: 0
- Been thanked: 0
LOL, it was half joking. I just looked at it and thought i'd say "capslock". BlackAura said that was one thing he was going to write up for his tutorials, so certainly he knows it. You could ask him if he could do that next.
If you have twenty monkeys,
banging randomly on typewriters,
they will in twenty minutes produce the complete source code to World of Warcraft.
banging randomly on typewriters,
they will in twenty minutes produce the complete source code to World of Warcraft.
-
- DC Developer
- Posts: 9951
- Joined: Sun Dec 30, 2001 9:02 am
- Has thanked: 0
- Been thanked: 1 time
I know (at least) three ways to do/simulate double buffering
Hardware double buffering - render the screen to a specific portion of video memory, then change the current screen pointer to that screen when you're done with it
Software double buffering - render the screen in main memory, and copy it over using DMA or store queues
Using textures - render the screen in main RAM and copy it to a texture in VRAM (or just render it to VRAM directly), then use the PVR hardware acceleration to draw that buffer to the screen.
Hardware double buffering is quite easy, but relies on mucking around with some of KOS's internals, which is why I haven't released it yet - I currently have no system I can use to build DC programs, and I don't want to release something like that without testing.
Anyway, I'll explain it here...
Normally, in 2D mode, the screen buffer starts at position 0 in video RAM, and extends as far as it needs to. This is all the video RAM is used for until you turn the 3D hardware on.
There is a function in KOS to change that screen pointer so that it points to somewhere else in video RAM. Basically, you pass it the VRAM address of the base of the screen (not the main memory address), and it'll immediately start displaying from that buffer.
That part's easy - now you just need to get a main memory pointer to it, so that you can write to it. That's quite easy too - you add the base address of video memory (can't remember it right now) to the address in video memory of the screen, and stick it into a pointer. Personally, I maintain a pointer to the backbuffer called vbuf_s (and another called vram_l), and vram_s (and vram_l) point to the currently displayed buffer, and are automatically set by KOS.
Then, you can easily build a flip function to switch between the two pages. Or three pages, or however many you want.
There is a better way though - KOS includes page flipping functions. However, the video modes are all set up so that they have only one page, so the page flipping functions will not work. There are two solutions - modify KOS (not a good idea), or hack the video mode tables at run time (which is a worse idea).
The PowerVR module does hardware double buffering, but I'm not exactly sure how.
Hardware double buffering - render the screen to a specific portion of video memory, then change the current screen pointer to that screen when you're done with it
Software double buffering - render the screen in main memory, and copy it over using DMA or store queues
Using textures - render the screen in main RAM and copy it to a texture in VRAM (or just render it to VRAM directly), then use the PVR hardware acceleration to draw that buffer to the screen.
Hardware double buffering is quite easy, but relies on mucking around with some of KOS's internals, which is why I haven't released it yet - I currently have no system I can use to build DC programs, and I don't want to release something like that without testing.
Anyway, I'll explain it here...
Normally, in 2D mode, the screen buffer starts at position 0 in video RAM, and extends as far as it needs to. This is all the video RAM is used for until you turn the 3D hardware on.
There is a function in KOS to change that screen pointer so that it points to somewhere else in video RAM. Basically, you pass it the VRAM address of the base of the screen (not the main memory address), and it'll immediately start displaying from that buffer.
That part's easy - now you just need to get a main memory pointer to it, so that you can write to it. That's quite easy too - you add the base address of video memory (can't remember it right now) to the address in video memory of the screen, and stick it into a pointer. Personally, I maintain a pointer to the backbuffer called vbuf_s (and another called vram_l), and vram_s (and vram_l) point to the currently displayed buffer, and are automatically set by KOS.
Then, you can easily build a flip function to switch between the two pages. Or three pages, or however many you want.
There is a better way though - KOS includes page flipping functions. However, the video modes are all set up so that they have only one page, so the page flipping functions will not work. There are two solutions - modify KOS (not a good idea), or hack the video mode tables at run time (which is a worse idea).
The PowerVR module does hardware double buffering, but I'm not exactly sure how.
-
- DC Developer
- Posts: 9951
- Joined: Sun Dec 30, 2001 9:02 am
- Has thanked: 0
- Been thanked: 1 time
The Dreamcast does have hardware page flipping, and it's possible to use it with KOS. The PowerVR drivers use hardware double buffering, and work quite well. However, you have to fiddle around with KOS's internal structures to get it all working properly.
I have a tutorial on it somewhere, but I might have lost it during the recent round of hard-drive formatting, and motherboard breaking...
I have a tutorial on it somewhere, but I might have lost it during the recent round of hard-drive formatting, and motherboard breaking...
-
- DC Developer
- Posts: 9951
- Joined: Sun Dec 30, 2001 9:02 am
- Has thanked: 0
- Been thanked: 1 time
Err... They're either on a backup CD, or somewhere on my hard drive. I never uploaded most of them. I probably should - I had code and tutorials for loading images, drawing images, drawing images with a transparent background, and I was experimenting with RLE compressed sprites, which are sprites that have been encoded so you can draw them much more quickly.
-
- DC Developer
- Posts: 9951
- Joined: Sun Dec 30, 2001 9:02 am
- Has thanked: 0
- Been thanked: 1 time
It's mostly because I didn't really think they were "finished" enough.
I did put some (slightly) cleaned-up versions of the tutorials available here on a website (http://files.frashii.com/~sp00nz/Doom/f ... Aura/tutes)
I did put some (slightly) cleaned-up versions of the tutorials available here on a website (http://files.frashii.com/~sp00nz/Doom/f ... Aura/tutes)
-
- DCEmu Uncool Newbie
- Posts: 1459
- Joined: Sat Dec 27, 2003 10:40 pm
- Has thanked: 0
- Been thanked: 0
- Contact:
yes ive seen this link in the topic but i didnt notice any other tut than the ones mentionned before.
if you ask me its better to share not so clean content than no content at all. plus if you keep them on a cd or on your harddrive for too long you will probably forget about them someday or dont get enough motivation to complete them later. so you would have wasted your time writing them, while people could already find it useful maybe.
i know you probably dont want to show them because you dont want to be annoyed by people asking for the same complementar infos again and again, but it could also avoid some questions posted here too frequently, dont you think?
if you ask me its better to share not so clean content than no content at all. plus if you keep them on a cd or on your harddrive for too long you will probably forget about them someday or dont get enough motivation to complete them later. so you would have wasted your time writing them, while people could already find it useful maybe.
i know you probably dont want to show them because you dont want to be annoyed by people asking for the same complementar infos again and again, but it could also avoid some questions posted here too frequently, dont you think?
- Edge-`
- DCEmu Cool Newbie
- Posts: 15
- Joined: Wed Mar 10, 2004 8:55 am
- Location: Kansas, US
- Has thanked: 0
- Been thanked: 0
I agree with Speud that it would be great to be able to see these tutorials, 100% complete or not. Your other tutorials (the ones already on your site) have been very helpful and speaking for myself I would love to see any information about some of the topics you've mentioned doing some work on. I would be happy to provide some webspace if needed as well if you are looking for places to store them.
Thanks BlackAura for the work you've done so far, if you would be so kind as to post some of your other tutorials, I for one would be very greatful for almost anything.
Thanks BlackAura for the work you've done so far, if you would be so kind as to post some of your other tutorials, I for one would be very greatful for almost anything.
-
- DC Developer
- Posts: 9951
- Joined: Sun Dec 30, 2001 9:02 am
- Has thanked: 0
- Been thanked: 1 time
I just wrote some examples to go with the first three tutorials, and have written/cleaned up a fourth, which is about hardware double buffering. It still needs a bit more cleaning up (and some more testing - I need to make sure the examples actually work properly), and then I'll release it. The examples (aside from the first one) have all the video code in two separate files (video.c, video.h) so you can just steal it and use it in your own programs.
I shall see what else I can dig up, or write.
I shall see what else I can dig up, or write.
-
- DC Developer
- Posts: 9951
- Joined: Sun Dec 30, 2001 9:02 am
- Has thanked: 0
- Been thanked: 1 time
Err... I actually completely forgot about them. I need to test the example programs I wrote to go with the first four tutorials.
Ah, the hell with it. If they don't work, complain loudly until I bother to fix them.
http://files.frashii.com/~sp00nz/Doom/f ... Aura/tutes
Ah, the hell with it. If they don't work, complain loudly until I bother to fix them.
http://files.frashii.com/~sp00nz/Doom/f ... Aura/tutes
-
- Mental DCEmu
- Posts: 415
- Joined: Thu Oct 10, 2002 7:18 pm
- Has thanked: 0
- Been thanked: 0
- Contact:
questions... but not necessarily for BlackAura
are those functions and variables (vid_empty, vid_mode->fb_base, vid_mode->fb_count) in KOS 1.1.6, 1.1.7 or 1.1.8 or higher?
b) are they in the manuals or programming examples (cuz i don't remember seeing them)?
why?
ok..... better yet, why is fb_size multiplied by 2 or 4 (besides the fact that it refers to two different video modes)? is fb_size in bytes, bits, or something that would make mulitplying by 2 or 4 necessary?
are those functions and variables (vid_empty, vid_mode->fb_base, vid_mode->fb_count) in KOS 1.1.6, 1.1.7 or 1.1.8 or higher?
b) are they in the manuals or programming examples (cuz i don't remember seeing them)?
Code: Select all
void dbuffer_init()
{
int fb_size;
// Calculate the size of a single page
fb_size = vid_mode->width * vid_mode->height;
switch(vid_mode->pm)
{
case PM_RGB555:
case PM_RGB565:
fb_size *= 2;
break;
case PM_RGB888:
fb_size *= 4;
break;
}
// Set the number of video pages to 2
vid_mode->fb_count = 2;
// Set the start positions of pages 0 and 1
vid_mode->fb_base[0] = 0;
vid_mode->fb_base[1] = fb_size;
// Empty VRAM
vid_empty();
}
ok..... better yet, why is fb_size multiplied by 2 or 4 (besides the fact that it refers to two different video modes)? is fb_size in bytes, bits, or something that would make mulitplying by 2 or 4 necessary?