paolo
Burger Head
Flash actionscript freak
Posts: 15
|
Post by paolo on Apr 24, 2007 13:45:30 GMT -5
since I don't feel confortable with tiles of sprites, or at least, I don't have any necessity since I'm a beginner.. I need to know how to istantiate a point, a single pixel, and whether there is the necessity, to clear the screen and redraw it.
My idea is to build some primitive functions to draw diagonal lines given 2 couples of coordinates.
And if you tell me how to do sine and cosine calculations on this basic ide, I can try to provide a realtime 3D example with easy explanation for everyone. I know I will never get textures to work (unless fps drop to zero) but I think that our megadrive processor can stand a simple 8 points rotation, and I want to test it, but don't have the basics for the commands of the ide (pixel drawing and math commands)
Thanks
Paolo
|
|
|
|
Post by haroldoop on Apr 24, 2007 22:00:42 GMT -5
Unfortunately, Mega Drive's uses a tile-based VDP, meaning that its video hardware wasn't designed for working with raster graphics. You can still manage to make a "fake" pixel-by-pixel drawing by changing the tiles on the fly. Unfortunately, I don't have any example for that in BASIC, but I do have one in C: www.sharebigfile.com/file/152213/POLY-zip.htmlI hope that helps! ;D |
|
paolo
Burger Head
Flash actionscript freak
Posts: 15
|
Post by paolo on Apr 25, 2007 8:29:33 GMT -5
too bad, I already know how to do it in C... you mean that there is not the possibility to lit a white pixel on screen on motorola 68000, sure  ? |
|
|
|
Post by Tom Maneiro on Apr 25, 2007 10:19:23 GMT -5
Sorry, you can't reference a single pixel in the screen because, as explained by haroldoop, the Genesis VDP uses tiles, not raw pixels...
Either you will have to go to the 32X (its VDP can do that, but, although BasiEgaXorz can work with it, it has NO documented 32X command set), or learn some complex tricks to do it in the Genesis.
|
|
paolo
Burger Head
Flash actionscript freak
Posts: 15
|
Post by paolo on Apr 25, 2007 17:13:21 GMT -5
wait, I understand what you say, but I'll give a last try on it explaining the hardcoding way to do it: in ooooold C, workin with vga (no multiplane sync or whatever, resolution fix to 640x480) some of you may remember well that the video memory (that should exist in all computers also Megadrive) was first memorized as a pointer (something like unsigned char far* MODE13 0x00000013h or similar pity me can't remember exactly) and then, just because video memory is an array long 640*480 = 307200 this way, whenever we say MODE13[50]=100 we lit the 50th pixel of the first row from top with the color 100. So, maybe in Megadrive assembler language, there should (I hope) be a similar, maybe not so easy but still reachable, way to do the same thing.
I ask this to someone here who *knows* how to reach and manipulate the hardcode way the addresses on the megadrive motherboard.
If this thing is inpossible, maybe just because there is not a reachable VRAM address... or because nobody out of japan knows it.. or remembers it... how can we workaround this problem? In informatics there is always a solution to everything..perhaps it will go flicky and slow.. but just to test! Any idea? some set of raster lines interpolated and tiled in order to map an arbitrary diagonal line? Some extern chip to put on the cartridge... whatever?
|
|
|
|
Post by haroldoop on Apr 25, 2007 21:55:00 GMT -5
It think you didn't get the point...  Actually, you can't do it as you described, due to the way MegaDrive's video memory is laid out, BUT by arranging the background map in a certain way, and changing the tiles on the fly, you can address individual pixels on the screen. That's what the program whose link I referred above does. It implements an (still unoptimized) all-pixels-adressable mode for the Sega Mega Drive. It compiles with SGCC 2.0 (a very old C compiler for the Mega Drive). |
|
paolo
Burger Head
Flash actionscript freak
Posts: 15
|
Post by paolo on Apr 26, 2007 4:02:59 GMT -5
wich link?  ok, so, if I create a tile 1x1 pixel I can use it as a movable pixel istance.. and do you know more or less how many istances the megadrive can swallow before drowning? How many thingies onscreen? |
|
|
|
Post by haroldoop on Apr 26, 2007 10:54:06 GMT -5
No. The tiles are fixed at 8x8 pixels. What I meant is that you could change individual pixels on screen by changing the tiles themselves. To have an idea on how this could be done, you can take a look at this (this implementation is not very efficient, though): www.sharebigfile.com/file/152213/POLY-zip.htmlOr you could use Stef's development kit for Mega Drive. One of the demos from his development kit renders a gouraud shaded cube on the Mega Drive at realtime, with a very acceptable frame rate. |
|
|
|
Post by jlf65 on Apr 26, 2007 14:58:05 GMT -5
Simplified example of what they mean.... think of the screen as being a 4x4 tile display like so:
Tile00 Tile01 Tile02 Tile03
Tile10 Tile11 Tile12 Tile13
Tile20 Tile21 Tile22 Tile23
Tile30 Tile31 Tile32 Tile33
Now you would normally predefine the tile, then change the references in the 4x4 array above. To do bitmapped graphics, what you do is fix the tiles to constant references and change the tile definition data. So the above screen would become hardcoded to
00 01 02 03
04 05 06 07
08 09 10 11
12 13 14 15
Then you modify your drawing routines so that when you draw a pixel, you draw it in the proper tile definition area. For example, drawing pixel 0,0 would require you to draw in the tile definition of tile 0. Drawing pixel 10,0 would require you to draw in the tile definition of tile 1. Drawing pixel 0,10 would require you to draw in the tile definition of tile 4. The screen stays hardcoded with the data shown above... it always points to the same tiles while the program changes the data that defines those tiles.
So tile 0 holds pixels 0,0 to 7,7, tile 1 holds pixels 8,0 to 15,7, etc.. Doing this, you can (fairly) easily do 16 color bitmapped graphics with the Genesis. Just remember that the Genesis display is actually 40x24 tiles (NTSC), not 4x4. ;D
|
|
|
|
Post by GiGaBiTe on Apr 26, 2007 18:49:21 GMT -5
I think that he thinks that the genesis VDP is like a framebuffer in QBASIC, which it isn't. Also, the sega can't do 640x480, its native resolution is 320x224 and you MIGHT be able to do 640x448 with interlacing.
Just think of the screen as a giant grid of 8x8 tiles, you can manipulate them but nothing smaller without changing the colors in the individual tiles.
|
|
oompa loompa
I AM THE GOVERNATOR 
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Apr 26, 2007 22:03:12 GMT -5
i think what you want is apa drawing, which is drawing blank tiles on the screen, and then changing the pattern data of those tiles, so that a pixel goes on and off. apa is hard to do on the genesis because you need to calculate which tile you need to modify, then calculate which byte. the hardest part is that each pixel is 4 bits long, and the bus is 16 bits wide there is an apa example that comes with basiegaxorz v0.19. there are 3 examples, i would use the one named apa2_fast.bex because that example has a routine to draw in apa that is made in assembly (fast  !). you need to initialize your tiles (so you can draw to it like a "frame buffer"). use this code:
disable screen
i=256
for y=0 to 27
for x=0 to 39
drawtile i,x,y
i++
next
next
enable screen
i started at tiles 256 because the font takes up tiles 0-255. if you don't want to use the font, you can always use these tiles for other things now, here's the assembler routine to actually draw pixels onto your "tile buffer" or whatever:
draw_dot_fast: ' Draw Dot converted to assembly language
' ~7000 Dots/second
regmove.l p,d7
regmove.l y,d0
regmove.l x,d3
asm
move.l d0,d1 ; Calculate dy
lsr.l #3,d1
mulu #1280,d1
move.l d0,d2 ; Calculate ddy
and.l #$07,d2
lsl.l #2,d2
move.l d3,d0 ; Calculate dx
lsr.l #3,d3
lsl.l #5,d3
move.l d0,d4 ; Caclulate ddx
and.l #$07,d4
lsr.l #2,d4
lsl.l #1,d4
move.l d0,d5 ; Calculate dddx
and.l #$03,d5
cmp.b #0,d5
bne @1
move.l #4096,d5
move.l #$0FFF,d6
bra @4
@1:
cmp.b #1,d5
bne @2
move.l #256,d5
move.l #$F0FF,d6
bra @4
@2:
cmp.b #2,d5
bne @3
move.l #16,d5
move.l #$FF0F,d6
bra @4
@3:
move.l #1,d5
move.l #$FFF0,d6 ; Calculate ddddx
@4:
move.l #8192,d0
add.l d1,d0
add.l d2,d0
add.l d3,d0
add.l d4,d0
move #$2700,sr
lsl.l #2,d0
lsr.w #2,d0
swap d0
move.l d0,($C00004)
move.w ($C00000),d1
and.l d6,d1
mulu d5,d7
add.l d1,d7
add.l #$40000000,d0
move.l d0,($C00004)
move.w d7,($C00000)
move #$2000,sr
end asm
return
that code can just be copy+pasted into your program. you really don't know what all the assembly does , and i don't think it's the fastest really (just the fastest i could get out at that time). when i said drawing individual pixels on the genesis was complicated, i did mean it (because of the architecture of the display controller) to use the routine, use something like this:
p = 1 ' p specifies which color to use (there are 16 colors, make sure to modify the pallettes, so that you don't get all black :D)
x = 123 ' x coordinate (0 to 319)
y = 90 ' y coordinate (0 to 224)
gosub draw_dot_fast
the apa2_fast.bex is a good example to get started in apa drawing . the example actually draws "circles" onto the screen i think it's better to get into drawing tiles + sprites because they're actually easier, and they can be reeeally fast on the genesis |
|
|
|
Post by jlf65 on Apr 27, 2007 16:38:22 GMT -5
Whatever happened to people's code reading skills? ;D
The main slow down is that it reads a word from the vram, sets the pixel data, then writes the data back to vram. If you can spare the memory, the best method would be to write to a buffer in work ram, then dma the data to vram after you're done with all your drawing.
|
|
?
!).