Page 3 of 3
Posted: Wed Feb 06, 2013 3:40 am
by Chilly Willy
djcouchycouch wrote:Thanks! I managed to draw a pixel
Is RLE mode implemented? There doesn't seem to be any code doing anything with it.
You can set it with Hw32xInit(), but you would need to do everything else yourself. The print routines are for 256 or 32K color modes. RLE isn't a very useful mode... it might make static screens a little smaller... or maybe it won't. It might make flat-shaded polys easier to render... or it might not. They should have left out RLE mode and used the extra gates for more drawing hardware than a plain line fill. You can see where someone thought it a great idea - all the old graphics formats used RLE encoding. They forgot to ask the programmers just how useful RLE REALLY was. While RLE COULD save a lot of space, in real world usage, you normally barely save 10%. Many images are actually BIGGER in RLE mode - it depends on how "busy" the image is. RLE depends on having large areas of flat color to save space.
Posted: Wed Feb 06, 2013 4:28 pm
by djcouchycouch
My current idea is to play around with flat shaded polygons so it appears interesting to me.
Any idea or docs about how RLE mode works in practice? Every pixel has a palette color index and a length, but it's not clear what happens with two adjacent pixels where the first pixel has a length that in theory overlaps the second.
Or is each line seen as a stack of paletteindex-length pairs with a maximum of 320 entries?
Posted: Wed Feb 06, 2013 8:52 pm
by Chilly Willy
djcouchycouch wrote:My current idea is to play around with flat shaded polygons so it appears interesting to me.
While at first it appears to be ideal for flat shaded polys, the RLE aspect means it's much more difficult to insert segments into a line, and hence much slower than just drawing the segment (using the line fill hardware, for example).
Any idea or docs about how RLE mode works in practice? Every pixel has a palette color index and a length, but it's not clear what happens with two adjacent pixels where the first pixel has a length that in theory overlaps the second.
Or is each line seen as a stack of paletteindex-length pairs with a maximum of 320 entries?
Every "pixel" is a word, and uses the same rules as 32K color mode.
The start of each line is determined by the line table.
Each "pixel" is of the form: MSB=length-1, LSB=palette entry.
The display stops after 320 pixels, even if more are indicated by the RLE, and starts at the next line indicated by the line table. So you don't have to worry about keeping line to exactly 320 pixels.
Hmm - looking at Hw32xInit(), I don't handle RLE mode. It would need another else if part for MARS_VDP_MODE_RLE that setup the line table like 32K mode. Like this
Code: Select all
else if (vmode == MARS_VDP_MODE_RLE)
{
// Set 16-bit direct mode, 224 lines
MARS_VDP_DISPMODE = MARS_224_LINES | MARS_VDP_MODE_RLE;
// init both framebuffers
// Flip the framebuffer selection bit and wait for it to take effect
MARS_VDP_FBCTL = currentFB ^ 1;
while ((MARS_VDP_FBCTL & MARS_VDP_FS) == currentFB) ;
currentFB ^= 1;
// rewrite line table
for (i=0; i<224/(lineskip+1); i++)
{
if (lineskip)
{
int j = lineskip + 1;
while (j)
{
frameBuffer16[i*(lineskip+1) + (lineskip + 1 - j)] = i*320 + 0x100; /* word offset of line */
j--;
}
}
else
{
if (i<200)
frameBuffer16[i] = i*320 + 0x100; /* word offset of line */
else
frameBuffer16[i] = 200*320 + 0x100; /* word offset of line */
}
}
// clear screen
for (i=0x100; i<0x10000; i++)
frameBuffer16[i] = 0;
// Flip the framebuffer selection bit and wait for it to take effect
MARS_VDP_FBCTL = currentFB ^ 1;
while ((MARS_VDP_FBCTL & MARS_VDP_FS) == currentFB) ;
currentFB ^= 1;
// rewrite line table
for (i=0; i<224/(lineskip+1); i++)
{
if (lineskip)
{
int j = lineskip + 1;
while (j)
{
frameBuffer16[i*(lineskip+1) + (lineskip + 1 - j)] = i*320 + 0x100; /* word offset of line */
j--;
}
}
else
{
if (i<200)
frameBuffer16[i] = i*320 + 0x100; /* word offset of line */
else
frameBuffer16[i] = 200*320 + 0x100; /* word offset of line */
}
}
// clear screen
for (i=0x100; i<0x10000; i++)
frameBuffer16[i] = 0;
MX = 40;
MY = 25/(lineskip+1);
}
That would leave the most space per line that the mode COULD require (the same as 32K mode). That also means 200 lines since there's not enough ram for more than 204 lines. If you wanted more lines, you'd have to assume that individual lines used less space than the max and enforce that during drawing.
Clearing the frame buffer for this mode is fine because 0 simply means 256 pixels of color 0.
Your drawing code would need to find the segment that holds the start of your new segment, split that segment, delete as many pixels as the new segment holds, and insert the new segment. While this is not complicated, you have to recursively search through the entire line until you find these points. Then you need to make the changes indicated, which may include shifting the contents of the rest of the line over an arbitrary number of words.
Posted: Wed Feb 06, 2013 8:58 pm
by Chilly Willy
Actually, thinking about it a bit, a better change for the Hw32xInit for RLE would be the change the
Code: Select all
else if (vmode == MARS_VDP_MODE_32K)
{
// Set 16-bit direct mode, 224 lines
MARS_VDP_DISPMODE = MARS_224_LINES | MARS_VDP_MODE_32K;
into
Code: Select all
else if ((vmode == MARS_VDP_MODE_32K) || (vmode == MARS_VDP_MODE_RLE))
{
// Set 16-bit direct or RLE mode, 224 lines
MARS_VDP_DISPMODE = MARS_224_LINES | vmode;
Also, from memory, the RLE example Sega did builds a linked list of segments which contain a link struct, the start point, the length, and the color. While "drawing" it actually inserts the segments into the link list. Then when drawing is complete, it goes back through the list and creates the RLE line from the info in the segment list.
Total noob here
Posted: Wed Feb 27, 2013 3:34 pm
by Snesi
Hi I keep getting error 127 when compiling it on Ubuntu 12.04, I have gcc-4.6.3 installed and I followed all the steps in the post.
These are last few lines that I get:
Code: Select all
> /home/nowcomputing/Downloads/logs/build-gcc-sh-elf-4.6.2-pass1.log
cd build-gcc-sh-elf-4.6.2; ../gcc-4.6.2/configure --target=sh-elf --prefix=/opt/toolchains/sega/sh-elf --without-headers --with-newlib --enable-languages=c --disable-libssp --disable-tls --with-endian=big --with-cpu=m2 --disable-werror
/bin/sh: 1: ../gcc-4.6.2/configure: not found
make: *** [build-sh2-gcc-pass1] Error 127
Please help, I really want to start md dev
Posted: Wed Feb 27, 2013 3:52 pm
by peekpoke
Where u extracted gcc-4.6.2 sources? According to your output, you need gcc-4.6.2 directory to be at /home/nowcomputing/Downloads/gcc-4.6.2, but makefile script cant find it there
To check, just run this command in ur console:
you must see in output at least those items:
bin
ldscripts
binutils-2.22
gcc-4.6.2
newlib-1.20.0
makefile-sega
Posted: Wed Feb 27, 2013 5:24 pm
by Chilly Willy
Downloads is where the arc is after downloading. You unarc the directories to wherever you put the makefile. I normally have a toolchains directory in the Projects directory, so the makefile will be in /home/jlfenton/Projects/toolchains/makefile, and the gcc directory in /home/jlfenton/Projects/toolchains/gcc-4.6.2, and so on.
The makefile expects all the directories to be in the same directory as itself. They don't NEED to be, but you would need to change the makefile to reflect where they actually were in such a case.
My toolchains directory has makefiles for all kinds of cross-compilers which all use the same gcc/binutils/newlib directories. That way I don't need a gcc/binutils/newlib directory for every toolchain I build.
Posted: Thu Jun 27, 2013 11:03 am
by notaz
Chilly Willy wrote:I'm not aware of any emulator yet supporting the CD mode 1 in 32X mode. I had to get that working completely on real hardware via flash cart. Fusion supports mode 1 in MD mode.
A bit of a gravedig, but I wonder if we have anything that uses this? I could of course cook something myself, but maybe somebody has something already.
Posted: Thu Jun 27, 2013 6:53 pm
by Chilly Willy
There was one commercial "game" that supported mode 1, but don't remember the name. There is a Sonic hack that uses mode 1, and my last update to Wolf32X uses mode 1. So there are a number of examples of using mode 1 available. If you wanted a specific mode 1 demo, I could put one together for you.
Posted: Thu Jun 27, 2013 8:13 pm
by Mask of Destiny
Chilly Willy wrote:There was one commercial "game" that supported mode 1, but don't remember the name.
Flux perhaps? I believe Pier Solar uses it as well.
Posted: Thu Jun 27, 2013 9:47 pm
by Chilly Willy
Mask of Destiny wrote:Chilly Willy wrote:There was one commercial "game" that supported mode 1, but don't remember the name.
Flux perhaps? I believe Pier Solar uses it as well.
Yeah, that's the one. And I can't believe I forgot Polo Solo.
Posted: Fri Jun 28, 2013 1:23 pm
by notaz
Well I'm looking for mode1 + 32x, so it's Wolf32X only then. The Wolf32X release thread (first post at least) doesn't seem to mention mode1 though.
Posted: Fri Jun 28, 2013 5:14 pm
by Chilly Willy
notaz wrote:Well I'm looking for mode1 + 32x, so it's Wolf32X only then. The Wolf32X release thread (first post at least) doesn't seem to mention mode1 though.
Yeah, I keep forgetting to update the OP - it's way back towards the end of the thread... or you can get it directly:
http://www.mediafire.com/download/dl6ba ... 0120223.7z
http://www.mediafire.com/download/h10gv ... OD-bins.7z
The first is the original Wolf32X+Mode1 release with source. The second is just the binaries where the only change was to double the size of the save ram (someone noticed that you couldn't save with the original size on the higher skill settings (too many bad guys/things)).