DCEmulation

This is the start of a fairly simple graphics tutorial, aimed at the Dreamcast. I'll probably do a better version later, with a couple of examples, diagrams, decent formatting, and stuff like that, but this is just a quick draft of the first part.

It's aimed mostly at people who have a little bit of graphics knowledge, and have already got all the DC development kit set up, and know how to compile stuff. Anyway, here it goes. Any feedback would be appreciated.

Setting up a video mode
The first thing you should do when doing any kind of graphics programming is set up a video mode. On the Dreamcast, this isn't really that important - KallistiOS will automatically set the video hardware up into 640x480, 16 bit 60Hz mode. However, it's still a good idea to set the video mode manually, in case they change something.

This couldn't really be much simpler - we just need to call the function vid_set_mode, giving it our desired resolution and colour mode, and it'll do the rest:


display_mode can be one of:


The 60Hz modes will always be 60Hz, even on a PAL Dreamcast. The 50Hz modes will always be 50Hz, even on an NTSC Dreamcast. While most PAL TVs can display a 60Hz signal, some can not, and virtually no NTSC TVs can display a 50Hz signal. So it's usually safe to use the 60Hz modes, but you might want to put in an option to use 50Hz on PAL Dreamcasts. I'll go into more detail on that later.

One rather strange omission that is worth taking note of - there is no 320x240 50Hz mode. I don't know why this is, because it's certainly not too difficult to do - it was just never included in KOS. If anyone really needs it, there is a patch to add that mode (DM_320x240_PAL) to KOS 1.2.0

pixel_mode can be one of:


The best mode to use on the Dreamcast is RGB565 - it provides fairly good colour quality, it's significantly faster than 24-bit mode, and it uses less memory. Just trust me on this - it's the best mode to use for pretty much everything that we're going to be doing.

So, to initialise the screen to 640x480 60Hz, in RGB565 colour mode, we'd use the following line:


RGB565 colour mode
In RGB565 mode, the three colour components are packed into two bytes. The upper 5 bits contain the red data, the next 6 contain the green data, and the last 5 contain the blue data. Red and blue range from 0 to 31, and green ranges from 0 to 63. The reason that green is given more space is because the human eye is more sensitive to green.

Colours on a computer are typically represented using three bytes - one each for red, green and blue, ranging from 0 to 255. There's an easy way to convert from this format to the 16-bit RGB565 format that we need - we just use a macro:


That macro uses two AND operations to mask out the unnecessary bits of the red and green components, bit shifts the values to get them into the correct place, and ORs them together. For some strange reason, that macro isn't included anywhere in KOS.

Drawing a single pixel
No matter how complex the graphics we're trying to make, no matter how many complex formulae and techniques we're using, no matter how long it's taken to draw our artwork, ALL 2D graphics come down to this - drawing a single pixel. For many things, where we need to plot multiple pixels at once, we can modify this routime to make it faster, but it'll still just be a variation on this. So how exactly do we draw a single pixel?

On the Dreamcast, the image currently being displayed on the screen is stored in an area of video memory called the framebuffer. The pixels are stored in order, from left to right, then from top to bottom, each as a single 16-bit value. So in order to find the location in the framebuffer of a single pixel, we can use this formula:


So, assuming a resolution of 640x480, we can do this:


Now all we need to know is where the framebuffer is. KOS provides us with a pointer to this location, named vram_s. So all we need to do the get the location in memory of a single pixel on the screen is:


From there, it should be easy to see how to draw a single pixel - we just need to set the value of that location in memory to the colour we want the pixel to be:


Clipping
Now that all works fine, until we come across one additional problem - clipping. What happens if we were to try to write to negative X or Y coordinates, or write off the bottom or the right of the screen? We'd be writing either to the wrong part of the screen, or an area of memory that we aren't allowed to write to. We could cause all kinds of problems. So we just don't do it - we have to add some checking to make sure we aren't trying to draw outside the screen:


Now we have a safe, effective way to draw a single pixel on the screen. Of course, it'd be more convenient as a macro:


Now, to draw a single pixel, we can just work out the colour we want to set it to using PACK_PIXEL, and the use DRAW_PIXEL to draw it.

Thanks a bunch, I'll be sure to save it for future reference. Just a question though, when running the PAL resolutions: would they have black borders like some of the DC PAL games? They all have the same no. pixels as the 60Hz equivalents, and as PAL has more vertical scan lines than NTSC, I'm assuming this will give those ugly black borders.

_________________
- Interesting.

You do get the black borders at the top and bottom of the screen, I'm afraid. It seems to be part of the DC's hardware. The screen resolutions are otherwise identical - same number of scanlines, same number of pixels per scanline. It might be possible to create a slightly hacked graphics mode that didn't have the borders, and thus had a higher resolution, but I don't know how well the rest of KOS would handle it, especially the stuff to handle the PVR.

So I think the best way is to detect a PAL console, and pop up a "60Hz or 50Hz" screen, like most commercial games do. It's not really that hard to code, and it's the only way that you can let everybody use the program, while still letting PAL users see it in full screen.

Strange, could have sworn some of my DC games ran fullscreen at 50Hz. Maybe it's only certain resolutions? *shrug* I'll have a look later. I'll be opting for a 60/50 selection screen in any case.

_________________
- Interesting.

Rather neat if any one wants i could do the same thing in SDL.

_________________


Join the Muppet posse!
http://www.dcemulation.com/phpBB/viewtopic.php?t=54866

As I said, there might be a tweaked resolution that doesn't have borders - as with most things that connect to a TV instead of a monitor, you have a lot of control over the way the signal's generated. But if there is such a resolution, KOS doesn't have it.

IM(r)eaper - Go for it. The more, the merrier.

I'm currently writing code for lines (horizontal, vertical, and arbitrary angled lines) and circles (filled and hollow), along with boxes (filled and hollow). The next tutorial will probably cover that lot. The hollow circles and the arbitrary angle lines are the hardest to do - they others are basically just simple loops combined with pixel plotting.

I'm guessing you can't create hardware anti-aliased vectors on the DC? I suppose it shouldn't be too hard to write a basic software AA algorithm. Eh, nevermind me, just thinking out loud again.

_________________
- Interesting.

I think you can actually, but you need to be rendering everything using the PVR hardware. And I don't know how to enable hardware AA on the DC. It can do it, I just don't know how. Oh wait... the PVR hardware can't actually do lines - you have to fake them using triangles. Should still be possible though.

I think that you could do anti-aliased lines in software. It shouldn't really be that hard - it's basically an extension of standard line drawing. But you'd have to be using double-buffering of some kind.

Ok With SDL ill try do the same thing as you in kos but with it. just working on my port having problems patching sdl when i get it fixed ill start writting the tuts. after that.

_________________


Join the Muppet posse!
http://www.dcemulation.com/phpBB/viewtopic.php?t=54866

Line drawing's nearly finished - horizontal and vertical lines are done, and I'm working on the general line drawing, using Bresenham's algorithm. It's not the fastest, but it's at least comprehensible. And, as an added bonus, I found an anti-aliased variant of it which I can use to do anti-aliased vectors. But that'll have to wait until I get to blending, which should be a real pain in the backside in 16-bit mode.

So, without further ado...

Horizontal Lines
Drawing pixels is probably getting kinda boring by now, so let's draw something more interesting. As a start, we'll draw a simple horizontal line, which is about the simplest shape you can do. A line is basically a load of pixels, arranged in a line. So they shouldn't be that hard to draw - we just need to draw a load of pixels in a line:


One problem there - what if x2 is smaller than x1? The line won't be drawn. So, if x2 is smaller than x1, we should swap them around:


And that's it... Or is it? The more observant of you may notice that this code is actually very bloated. Remember that DRAW_PIXEL is checking if the pixel is on the screen for every pixel we draw. But, since this is just a horizontal line, we know that if both points are on the screen, the whole line is on the screen. If the line's off the screen entirely, we can just ignore it. If the line is on the screen, we can tell how much of the line is on the screen, and adjust the left and right coordinates appropriately. So we can do this:


That's a bit better, but there's still one problem - for each pixel, we're doing y*640, which will be the same for each and every pixel. In face, since we're drawing from left to right, each pixel will be next to the previous pixel. So we can do something like this:


That probably won't make a lot of sense unless you know something about pointers in C - line_buffer is set to the location of the first pixel of the line we're drawing. We then draw the pixel, and increment line_buffer by one pixel, so it now points to the location of the next pixel.

A horizontal line is actually far more useful than it would first appear. A horizontal line is very useful for drawing filled shapes - you just draw a horizontal line from the left-most point of the shape on a given line, to the right-most point of the shape. Then you repeat that for each line. That's how most software rendered 3D games fill polygons.

Vertical Lines
These are pretty much exactly the same as horizontal lines. However, we're now drawing down instead of right. Basically, we swap the X and Y coordinates around, and we skip 640 pixels instead of 1 - we jump down one pixel instead of right one pixel:


Hollow Boxes
Now that we have the code to draw horizontal and vertical lines, drawing a hollow box should be very easy - we just draw tow horizontal lines, and two vertical lines:


Filled Boxes
All we do here is draw a series of horizontal lines, which will fill an area of the screen. We know what the left and right coordinates of the box are on each scanline, and we know how far up and down the box goes. So we can just do:

I figured I'd throw some knowledge in the ring, especially since I just started working with PVR code in my game again. So, without further ado, a PVRized version of the lines tutorial.

Initialization:

Just a few little differences between regular, and PVR init. First of all, set your video mode, like BlackAura stated above. Immediately after this, you need to initialize the PVR, if you'd like to use it. This can be done most simply like this:

This will set up the PVR with reasonable defaults for all settings. I've never had to muck around with the settings, and I find the defaults to be pretty good.

Scene Drawing:

When using the PVR, one needs to tell it when beginning a new scene, and what polygon lists will be used. This is done as follows. (You also must close everything when you're done with it!)


Horizontal Lines:

Horizontal lines are fun, aren't they! Anyway, here's a method I use to draw horizontal lines of any color on the screen.


Simple enough, eh? For this function, you can pass in values between 0 and 255 for each color (r, g, and b) and how opaque it is (a).

Vertical Lines:

Once again, the wonderful vertical line. Here's my method of drawing vertical lines:


Arrows (AKA Triangles):

Just a short note about triangles. All verteces need to be submitted clockwise. The same goes for the diagonal line function later. These functions have no protection for if someone submits them in the wrong order, and most likely, there will be no triangle on the screen if you do.


Diagonal Lines:

The last thing I'll be covering, at least today, is diagonal lines. Remember Coordinates must be put in in a certain order. (see note below code)


This diagonal line code should be able to handle any kind of line, I just use the horizontal and vertical line routines above. Anyway, here's the note I mentioned above:

Will draw a line like this slash: / that is white, and completely opaque.

Will draw a completely opaque, white line that looks similar to this slash: \

That's all for today, let me know if you see any improvements, or problems with this tutorial lesson.

It's indeed weird that that mode was missing. Anyway, I talked about that with Mekanaizer on #dreamcastdev a few months ago. He had a text file which explained the video registers and he submitted a patch to add that mode. It's now included in CVS, so it will be included in KOS 1.2.1 as well when it comes out.

But I always use CVS anyway.

Shouldn't that bit say 60Hz? 50Hz is the PAL standard, and so all PAL TVs will display 50Hz, with most displaying 60Hz.

Yeah, it should... I'll just go back and edit it. Thanks for pointing that out.

BlueCrab - Nice job.

Thanks, thought it'd make a good addition when I saw this topic.

Those lines are being draws as a quad, yes? It might have been a better idea to cover drawing triangles first, since they're slightly simpler than quads. And, while you're at it, you could have done a filled rectangle quite simply too.

I've been converting the stuff I've got into HTML, writing some examples for each tutorial (up to part 4 now) and preparing to put it up as a webpage. D'ya mind if I put that up too?

Well, I have drawing triangles in there too! I'll add some stuff with more general filled quads in a bit. And sure, you can include the tutorial, just make sure I get the proper credit, ok? And feel free to rearrange the stuff in the HTML page...

Drawing Filled Rectangles with the PVR:

Drawing filled rectangles with the PVR is just as easy as drawing those lines earlier.



And that's how you draw filled rectangles with the PVR.

Cool, thanks! I'll put it up there when I get around to it - I'm still working on converting my own ones and writing some examples to go with them. Line clipping is proving to be more of a pain in the neck than I thought...

I am using visual c++ and kos 1.9, and the following "vram_s[x + (y * 640)] = PACK_PIXEL(r, g, b); " would not work for me. Is this method not supported in 1.9?