I did this a long time ago, but it just crashed...

now that I upgraded my gcc version


http://www.screamcast.net/staff/Quzar/guess.jpg
http://www.screamcast.net/staff/Quzar/guess1.jpg
http://www.screamcast.net/staff/Quzar/guess2.jpg
http://www.screamcast.net/staff/Quzar/guess3.jpg

if you can guess what this is, you win a prize!

TG16 emulator with badly corrupted graphics?

oh yeaaaaaa.

its actually Hugo! . This was the first thing I ever attempted to port, and i saved the files just because it seemed to crash for no reason. Now I tried compiling it again without touching the sources and it didnt crash. When I did it though I ended up mostly just commenting out anything that wouldnt compile, so now I'm gonna try again, see if I can make it actually work =P,

So where's my prize?

Kidding... Actually, I had no idea what it was until I did a search for "Soldier Blade", which turns out to be a PC Engine / TG16 game.

oh well, i was gonna give you a prize, but that disqualifies you =P.

you could have won a compiled bin of it :P aka a useless bin file that ouputs mostly random colors in non-random colors to your screen hehe

I have enough copies of Genesis Plus that do that, and far worse...

very cool quzar, good luck

yeah nice to see you having a go ;)

http://www.screamcast.net/staff/Quzar/hugo.jpg

I just finished reporting it (started at 10:30 am after taking a midterm =P been working since then [its 830pm here hehe]). I need to write some DC specific input code instead of the cruddy hacked SDL stuff.

http://www.screamcast.net/staff/Quzar/SoldierBlade.jpg

I centered the screen correctly and fixed the graphic issue =). Now to just implement controllers hehe.

Nice work! Good luck with this! ;D

wow your going to be very popular when u release! btw whats the speed like?

frankly the speed is crap. Ive already managed to pretty much double it thoug by removing SDL controls, but it still has a long way to go.

What kind of setup (KOS/SDL/Whatever, compiler, newlib/koslibc) are you using at the moment?

From the specs, it sounds like you'll have the same kind of speed problems we've been having with Genesis Plus. If you can find some technical documents on the PCE's graphics hardware, you might be able to pull off the same stunt I did with Genesis Plus. Assuming there's nothing completely insane about the graphics hardware (and there might be - look at the NES or the SNES for example), it might actually be easier, because the graphics hardware seems a lot less flexible than the MD's...

Just found some documentation on it...

http://cgfm2.emuviews.com/txt/pcetech.txt

It seems that the PCE's graphics hardware is quite similar to the MD. The three main differences:

More available colours (256 for backgrounds, 256 for sprites)
Only one background layer
Tile data is stored in planar format (aaaaaargh!)

So, actually rendering things to the screen using hardware acceleration would be easier, assuming few games need really accurate emulation, and converting the tile data into a usable format would be much harder...

frankly i dont know how to do that. not only would i be at a loss without studying the code already in hugo, at the moment its all so cluttered that i can barely understand it.

my setup is kos 1.1.9/ SDL that ian released on his site [not sure whatversion] , gcc 3.3.3, and the libc is the kos 1.1.9 version.

also, what i really need is documentation on the SuperGraphx because as far as i can tell, this emulates that, not the original TG-16/PCE

http://www.screamcast.net/staff/Quzar/ys3.jpg
http://www.screamcast.net/staff/Quzar/ys31.jpg
http://www.screamcast.net/staff/Quzar/ys32.jpg

For anyone familiar with this game, you'll know that its a CD game =).

Doing hardware acceleration for a Supergrafx would probably be more difficult than a MegaDrive, actually. The Supergrafx has two separate video chips, and the output is composited by an extra video chip, based on all sorts of funky things. I did find some documentation on it though, which is only useful if you have the TG16 documentation too.

http://cgfm2.emuviews.com/txt/sgxtech.txt

The same guy who wrote boththose documents also wrote Genesis Plus, the documents I've been using as a reference for the MD VDP, and a TG16 emulator. His code is probably a lot neater than the HuGo code, so you could probably read through that and compare them. The only way I managed to understand the MD VDP as well as I do (which isn't all that well) was by studying the documentation, a couple of MD emulators, and writing an emulator for it.

Of course, you shouldn't bother doing that until everything else works as well as it's going to, and even then only if you can't think of a better way to speed it up. It's kinda tricky, mostly because dealing with the Dreamcast's hardware is tricky.

Speaking of which, nice job getting CD emulation working. Is that running from a CD image, or a CD?

Whats funny is that it actually has run CD games the whole time, i just hadnt tried =P. Its running off an ISO. I have yet to test an actual CD but I seriously doubt it would work because I had to hack out some key CD reading funcions in order to get it to compile (ive gotta figure out how to re-write that later =\). I'm also not sure wether or not it can read the mp3 files corresponding to the isos (or how this will affect speed).

The next biggest thing I need to do is rewrite the SDL rendering to PVR rendering. Right now the way it works is that there is are multiple 'osd' versions of the screen display routine, while the core renderer is portable. Ill be looking at a few DC emulators to see about how to do so.

The MP3 decoding will just slow things down too much. Unless it's running well above 100%, then it's not worth it. It you get support for real CDs working, it won't even be necessary - you can just use CD audio. Failing that ISO + uncompressed WAV would work...

I wouldn't bother with a PVR renderer at the moment. Unless you want to be able to stretch the screen easily, it would be easier to just dump the image directly into the framebuffer. If the video output is 16-bit anyway, this should be very easy. If you need to do any kind of pixel format conversion first, it can get a little trickier, but no trickier than using the 3D hardware. Get it into 16-bit colour format, then copy it over using store queues.

Actually, I do kind of need screen size manipulation, because right now that is done in software by SDL.

You're doing software stretching? No wonder it's running slowly.

Looking at the specs, unless you want games to have borders at the sides, you probably do need stretching.

[quote author=BlackAura link=board=pdev;num=1098164880;start=15#20 date=10/21/04 at 08:31:31]You're doing software stretching? No wonder it's running slowly.[/quote]

I actually prefer things running at the proper aspect ratio which this thing to a point ignores (well it doesnt really, but SDL on the DC can only do certain heights/widths, which i didnt even know it could do 640x480, i thoutht it was limited to 320x240 =P). wether or not they take advantage of extra resolution or not.

Its not my fault the program did it that way =P its just not one of the things i wanted to tackle right away =P (remember this port is 2 days old hehe)

Anyone know why I might be getting this error: "thd_schedule: idle task is the only thing left; exiting"

using the code I posted here for pvr display: http://www.dcemulation.com/phpBB/vie...amp;highlight=

it seems to throw that error or outright hang soon after running that (it seems to be some sort of timed thing, since the place in code depends on how many things have to run ( i comment out the last line that seemed to be the problem, and it just happened slightly later).

are you creating your texture with
vidram_tex = pvr_mem_malloc(TEX_WIDTH*TEX_HEIGHT*2);


did you call pvr_setup() somewhere else?

also is your buferr 32 bit aligned?
osd_gfx_buffer = (unsigned short *)memalign(32,256*256*2);

Otherwise I don't know what else it could be.

my pvr init code:

Code:

---


int osd_gfx_init(void)
{
  pvr_init_defaults();
  vid_set_mode(DM_320x240, PM_RGB565);
  vidram_tex = pvr_mem_malloc(256*256*2);
    osd_gfx_buffer= (unsigned short *)memalign(32,256*256);
    return 1;

}

---

i also tried using this :KOS_INIT_FLAGS(INIT_DEFAULT & ~INIT_THD_PREEMPT);

to do that different thing possible with the threading (which I frankly just don't understand at all)

ok, I am not familiar with those KOS flags but

have you tried to use these funtions to load the pvr texture instead of memcpy it?

pvr_txr_load_dma(vidram_buf, vidram_tex, TEX_WIDTH*TEX_HEIGHT*2, 1,NULL,1);
or
pvr_txr_load (vidram_buf, vidram_tex, TEX_WIDTH*TEX_HEIGHT*2);

what I would try is set up a buffer thats memaligned like my above vidram_buf, and memcpy to it . And then use one of the above function to load the texture. Don't know if it will make any difference.

Troy

[quote author=GPF link=board=pdev;num=1098164880;start=15#25 date=10/24/04 at 03:53:52]ok, I am not familiar with those KOS flags but

have you tried to use these funtions to load the pvr texture instead of memcpy it?

pvr_txr_load_dma(vidram_buf, vidram_tex, TEX_WIDTH*TEX_HEIGHT*2, 1,NULL,1);
or
pvr_txr_load Â* Â*(vidram_buf, vidram_tex, TEX_WIDTH*TEX_HEIGHT*2);

what I would try is set up a buffer thats memaligned like my above vidram_buf, and memcpy to it . And then use one of the above function to load the texture. Don't know if it will make any difference.

Troy[/quote]

I actually already tried exactly what you said before and it does the same.

The weird thing is this didnt happen at first. It happened once randomly then not again for a while, and now it happens no matter what I do.

I'm gonna try writing the pvr rendering again from scratch i guess =\.

Still kindah wanna hear what BA has to say about it (if anything =P)

I notice you are using pvr_init_defaults();
is that the same as pvr_setup();

I have only used pvr_setup();
what the difference?

ive never seen pvr_setup. i think that might be a newer way of doing pvr_init_defaults but im not sure.

oops my bad.

pvr_setup is my own function that calls pvr_init_defaults() lol , sorry