Any more ideas? I exhausted most of my ideas the other day, but what I would do if I were you is to write a lean program that only deals with displaying translucent images. I don't imagine that your program is very large at this point anyway, but even a little excess clutter might inhibit you from ...

Well I've got this CD stuff sorted out, it's still kinda tedious but it works so I'm happy :grin: Although I'm still stuck with the alpha blending issue. For some reason when I use the PVR_LIST_TR_POLY it doesn't even start up with the spinning swirl thing it does. Just a black screen. Because it ru...

Basically, you'll need to have a disc that has some sort of program like demomenu or dchakker burned as a selfboot disc. Then you'll burn your unscrambled binary and data on the disc in a multisession format (without bothering to make it selfbootable or anything like that). Boot from the demomenu/d...

I'm not going to completely dissuade you from building or purchasing a coder's cable -- they are indeed convenient -- but I want to encourage you to keep trying with CDs in the meantime. If CDs are costly, then consider reusing them multiple times (I'm not talking about a CD-RW). You can test multi...

Okay CD's are getting tedious. I think I'm going to have to step back from devving and get a coders cable sorted out now to be honest. I see what you all mean when you say if I'm serious about DC development I should get one. Now I've looked at various articles and tutorials on making a coders cable...

Tried all that and cleared up my nooby mistakes.....No difference in the emulator and my dreamcast isn't even booting into it now

I'll see if I can get that one figured out but the transparent problem remains a mystery

class VideoSystem { public: VideoSystem(); ~VideoSystem(); void Initialize(); bool Loop(); void Flip(); void DrawPolygon(Eternal::Rectangle *,float r, float g, float b); private: pvr_poly_hdr_t hdr; }; Eternal::VideoSystem::VideoSystem() { } Eternal::VideoSystem::~VideoSystem() { } void Eternal::Vi...

Is it possible that you're feeding CR+LF line endings (e.g. from a Windows-based text editor) into a library that expects LF line endings, and thus getting a trailing CR included in your string? ....I guess you're talking about the the GCC problem? Because it was *something* to do with the end of t...

This actually could be a problem with GCC....Does newlines get read in as part of a string with std::getline() for fstream or something similar? Because hardcoding the path makes it run fine :o I have to admit I'm a Visual Studio fan.... :( Quite possibly. I know if you're using the C function fget...

It's all starting to come along pretty well now so long story short I have a map: http://i56.tinypic.com/50fqtl.png The black is the transparency because I the map itself has 3 layers. Ground, Top, and above. I couldn't render each tile with the Z position at 1 so I had to increase the depth by 1 fo...

Thanks again guys, I admit I'm not a huge GCC fan because I learned to program on Visual Studio so it feels unnatural. Turns out it was a newline so I had to swap some things to char pointers and others I could just do: str.erase(str.begin()+str.length()-1); Hopefully I'll be nearing the end of my n...

This actually could be a problem with GCC....Does newlines get read in as part of a string with std::getline() for fstream or something similar? Because hardcoding the path makes it run fine

I have to admit I'm a Visual Studio fan....

Yeah I've figured this much out. But I don't understand why it can't read the file :? I've checked that the file is and path is correct several times and it's just a simple PNG like the previous one I had tested with. The only difference is the size. If it's not the path then perhaps it's something ...

Sure but I doubt it's not finding the file though because it runs fine on PC (this is multiplatform) Here is how I load the image: void Sprite::Load(const char *filename) { std::string f = "/cd/"; f += filename; png_to_img(f.c_str(), PNG_FULL_ALPHA, &kos_img); p_Texture = pvr_mem_mallo...

This is going great so far. Although I've hit another brick wall, I tried to load a bigger image such as 512x512 which I often use in my games for tilesheets but I get this error: http://i51.tinypic.com/2udvm92.png I don't understand what's different as they're both PNG's and the only difference I'm...

That's cool thanks!

When you say the kos_img_t will be in the main RAM, what about when I call kos_load_kimg() will the pvr_ptr_t be stored in the VRAM?

I had another problem but I spoke to soon it's fixed!

Thanks.

Ah is it difficult in to do in code? Because I like the idea of having a single color that will automatically be transparent. Some artists prefer this method and it helps when using simple image editing software.

Can't you just loop through each pixel and set its alpha value like that?

That all sounds cool apart from: set the color to fully transparent in the image data itself Uh...I don't quite understand. I guess you mean I pass the PVR_MASK_ALPHA or PVR_MASK_FULL_ALPHA and use PVR_LIST_TR_POLY but I'm not sure what you mean about set the color to fully transparent itself. You m...

This shizzle is working!

Thanks guys! Especially you BlueCrab!

EDIT:
One last question: How about color keying? I had to pass a flag for the kos_img which PNG_FULL_ALPHA I guess should be used? So basically how would I go about setting a specific color to full transparency?

Okay I've got another problem it would seem. I'm trying to make a basic library to handle this stuff behind the scenes just as something to work on instead of a lot of test programs. I noticed that pvr_poly_hdr_t and pvr_poly_cxt_t need to be declared in the same scope as your infinite loop and be r...