So I've got off the ground.

[N64VSNES]

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 but they go over to the top my head and buying one would cost £20-£30 (more than I paid for the dreamcast).

So does anyone have any suggestions to where I can get one cheap or how I can understand making one a little better? I've really never done any wiring or anything so I guess that's why the tutorials are so confusing.

Thanks.

[EnigmaticCoder]

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 multiple versions of your game on a single CD.

Coder's cables, as an alternative, still have a couple of steps to test your game. When I use my broadband adapter, I run arp to assign an IP address to my BBAs mac address (once per reboot of my computer), move my .elf binary to the same directory as the dctool program, turn on the dreamcast, wait for it to be ready to accept the binary, and then run a command to send the binary across the ethernet cable. As you can see, there are nearly as many steps to this procedure as there are to burning a CD. After you burn a few CDs, the process becomes routine. Thus, the coder's cable is a high price for what it's worth, (although I'm glad I have my BBA).

Consider testing less and writing code for longer periods of time. Once you learn how to initialize KOS, draw images to the screen, play music and sound effects, and use the VMU, creating Dreamcast games is like creating games for the PC, with the only substantial difference in memory and processor constraints. I suppose you don't have the niceties of certain libraries, but let me get back on point. You're getting over the initial hurdle of learning how to use KOS. You won't need to test your game as often until you start finding bugs. What I'm trying to get at is that lack of a coder's cable will be less important after this initial learning curve.

I'm not saying, "Don't buy a coder's cable," but rather, "Keep working at it until buying a coder's cable becomes economically feasible."

[N64VSNES]

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 multiple versions of your game on a single CD.

....Someone should have told me this

I'm definitely getting a cable and I'm definitely not just "stopping" until I get the cable but I do think I need to slightly step back until I can test this stuff properly. I hate wasting peoples time because I'm drawn to emulators and they're arising problems that aren't problems.

So how would I test multiple times with the same disk? I've heard with fancy software you can skip finalizing the disk and then add stuff on top of it later but wouldn't the dreamcast get confused with multiple "FIRST_READ.BIN"'s on the disk?
Do teach master warlock!

[BlueCrab]

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/dchakker disc, swap discs, then boot your binary.

The first 6 months or so that I was doing DC Development (back in like 2002) that's how I did it.

[N64VSNES]

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/dchakker disc, swap discs, then boot your binary.

The first 6 months or so that I was doing DC Development (back in like 2002) that's how I did it.

If there is one thing I learned about you guys, it's you'll do anything to raise the population of the dreamcast scene

So basically I would do:

1- Burn either demomenu ir dchakker to a disk
2- Also burn the program
3- Dont finalize it?
4- Burn more to it?

[OneThirty8]

You'll want to burn DemoMeno or DCHakker to a selfbooting disc all by itself using whatever method you normally use to make a selfbooting disc. I always used DemoMenu. This is the disc you'll put in your Dreamcast when you turn it on. Once it loads up, you will swap in your multi-session disc with the binary to be tested and game data. Press B (I think--it's been a while) to refresh the menu. If your binary is scrambled, select it in the menu and press Y, and then A. If your binary is unscrambled, find it in the menu and just press A.

To make your multisession disc, use any CD burning software and just leave the disc open so you can burn another session later.

[N64VSNES]

Well I've got this CD stuff sorted out, it's still kinda tedious but it works so I'm happy

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 runs anyway in a emulator I can't get any of the debug output I normally have so I'm not sure if it has crashed or where it might have crashed. I added some space for translucent list and made sure the depth values were fine...This is very weird.

Any more ideas?

[Ex-Cyber]

Not all burning programs will do it. DiscJuggler might not have it since the main purpose of DiscJuggler is to do small-scale production runs (the "juggler" part comes from its ability to run multiple burners at the same time). InfraRecorder should be able to do it (the underlying program it uses to burn is capable of it), but I don't remember whether it actually exposes the option.

[EnigmaticCoder]

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 locating the problem.

[N64VSNES]

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 locating the problem.

haha, it looks like that's currently the only alternative left xD I'll let you all know if I get it working later

[N64VSNES]

Ooookay....I thought you said transparency wouldn't work on emulators?

This works as intended in a emulator but doesn't even load in the actual dreamcast (just grey screen):

Code: Select all

#include <kos.h>
#include <pvr.h>

#include "Rectangle.h"

pvr_poly_hdr_t hdr;

void Initialize() {
	pvr_init_params_t init_params = {
	{ PVR_BINSIZE_16, PVR_BINSIZE_0, PVR_BINSIZE_16, PVR_BINSIZE_0, PVR_BINSIZE_0 }
		, 512 * 1024
	};
	vid_set_mode(DM_640x480,PM_RGB565);
	pvr_init(&init_params);

	pvr_poly_cxt_t cxt;

	pvr_poly_cxt_col(&cxt, PVR_LIST_TR_POLY);
	pvr_poly_compile(&hdr, &cxt);
}

void DrawPoly(Rectangle *p, float a, float r, float g, float b) {
	pvr_vertex_t vert;

	vert.flags = PVR_CMD_VERTEX;
	vert.x = p->x;
	vert.y = p->y + p->w;
	vert.z = 1.0f;
	vert.u = vert.v = 0.0f;
	vert.argb = PVR_PACK_COLOR(a, r, g, b);
	vert.oargb = 0;
	pvr_prim(&vert, sizeof(vert));

	vert.y = p->y;
	pvr_prim(&vert, sizeof(vert));

	vert.x = p->x + p->w;
	vert.y = p->y + p->h;
	pvr_prim(&vert, sizeof(vert));

	vert.flags = PVR_CMD_VERTEX_EOL;
	vert.y = p->y;
	pvr_prim(&vert, sizeof(vert));
}

int main(int argc,char **argv) {
	Initialize();
	Rectangle rect;
	rect.x = rect.y = 200;
	rect.w = rect.h = 64;
	while(true) {
		pvr_wait_ready();
		pvr_scene_begin();
		pvr_list_begin(PVR_LIST_TR_POLY);
		pvr_prim(&hdr,sizeof(hdr));
		
		rect.x = rect.y = 0;
		rect.w = 640; rect.h = 480;
		
		DrawPoly(&rect,1.0f,0,0,1);
		
		rect.x = rect.y = 200;
		rect.w = rect.h = 64;
		
		DrawPoly(&rect,0.1f,1,0,0);
		pvr_list_finish();
		pvr_scene_finish();
	}
	return 0;
}

Rectangle.h:

Code: Select all

#ifndef RECTANGLE_H
#define RECTANGLE_H

class Rectangle {

	public:
	Rectangle() {
		 x = y = w = h = z = 0;
	}
	~Rectangle();

	float w, h;
	float x, y;
	float z;

};

#endif

This is the program I slung together outside what I was working on....Wise words are much appreciated

EDIT:
I'm really stuck here......It makes no sense that using a different list would prevent it from booting, and the fact it works in a emulator just confuses me even more.

[BlackAura]

Ooookay....I thought you said transparency wouldn't work on emulators?

Transparency works. Automatic depth sorting doesn't.

The Dreamcast's 3D hardware will automatically depth sort transparent polygons, and draw them in order from back to front. Emulators just draw all the transparent polygons in the order they're in the display list, without sorting them. If you want to get the rendering order right on the hardware, you just need to set the right Z coordinates, and the hardware will handle it for you. On an emulator, you'd have to sort the polygons by depth before drawing them, just as you would using Direct3D or OpenGL.

None of that would affect your test program. It should work the same on a Dreamcast and an emulator.

This works as intended in a emulator but doesn't even load in the actual dreamcast (just grey screen):

Gray screen? That means it's probably loading. Otherwise, you'd just get black. Or, more likely, a reset. Most code-related problems just cause an immediate reset.

A gray screen would suggest to me that the PVR's having some problem with the instruction stream / display list. That might also explain why it's working in an emulator - the code's probably running fine, but the emulator's display list processing doesn't exactly match the real hardware.

The only thing I can think of - it works if you use the OP list instead? Maybe the PVR needs an opaque polygon list? I don't remember it being required, but I also don't remember ever trying to render a scene with no OP list.

At the beginning of the frame, you could try something like this:

Code: Select all

      pvr_wait_ready();
      pvr_scene_begin();

      // Insert a blank OP display list.
      pvr_list_begin(PVR_LIST_OP_POLY);
      pvr_list_finish();

      pvr_list_begin(PVR_LIST_TR_POLY);

Edit:I just looked at some of my old code. Genesis Plus / DC renders everything to the TR and PT lists, but it actually creates an empty OP list as well. I can't find any other code I've written that doesn't render something to the OP list first.

The other usual problem that causes something to crash on a Dreamcast but not an emulator is an unaligned memory access - trying to read a 4-byte value from an address that's not a multiple of 4, for example. The x86 ISA allows it, while the SH-4 does not. It usually causes a reboot though.

[N64VSNES]

Same result

However I've noticed the is a little square on the screen which is faint but visible. So the scene IS actually rendering. But the colors are grey.

Does this help any?


EDIT:
Wow this is even stranger, if I keep looking at the screen the colors quickly flash into place and disapear again. The time between the flashes seem random but it goes into full color.

[EnigmaticCoder]

I haven't read your code, but colors flashing into place seems almost like the polygons are "competing" for the same depth. Try drawing them at different depths.

[N64VSNES]

I haven't read your code, but colors flashing into place seems almost like the polygons are "competing" for the same depth. Try drawing them at different depths.

You're absolutely right!

Cleaned up some stuff back in my original project and it works. Thanks man!

EDIT(4):
...Nevermind haha xD

Thanks again!

[N64VSNES]

You can also make romdisks that you can mount and unmount at will at runtime, but that's a different story.

Yeah romdisks are a great idea but I need to use the cd for this project since it's originally for the PC
I guess if I get daring I could try and make some sort of virtual romdisk system for the PC


Also I've ported the EQ(eternal quest) engine. If anybody wants I'll post some screenshots or maybe a thread about it

EDIT:
One last problem: I need to port the new version of lua and tolua++ but uh....I've been babied with IDE's....Halp? lol

EDIT EDIT:
I've managed to get tolua++ running because it's pure standard C++ so it didn't need compiling but as for lua itself.....I really need some help here, I'm clueless

[PH3NOM]

If your programs fits barely in ram or it crashes ( kernel panic : out of memory ) there's always a last resort option and that's disabling the debug in kos, you can get up to 3-4 MBs this way BUT some memory allocation *might* stop working ( not sure about that last part But I remember reading about it and having some problems in ports when disabling it, but only rare cases )

How do you disable the debug mode?

I am running out of RAM for DCMC, and an extra 3-4mb could make or break the project at this point...

[patbier]

Hello Ph3nom,

look at kos/kernel/libc/koslib/malloc.c

Code: Select all

/* Enable to allow extra debugging checks in the malloc code itself.
   This sometimes catches corrupted blocks. Recommended during debugging
   phases. */
#define DEBUG 1

/* Enable this define if you want costly malloc debugging (buffer
   sentinel checking, block leak checking, etc). Recommended during
   debugging phases, but you should probably take it out before you
   start your final testing. */
#define KM_DBG

/* Enable this define if you want REALLY verbose debugging (print
   every time a block is allocated or freed). Only enable this if you
   are having some serious issues. */
// #define KM_DBG_VERBOSE

If you comment
#define DEBUG 1
and
#define KM_DBG

you'll stop kos extra debug.

[PH3NOM]

Hello Ph3nom,

look at kos/kernel/libc/koslib/malloc.c

Code: Select all

/* Enable to allow extra debugging checks in the malloc code itself.
   This sometimes catches corrupted blocks. Recommended during debugging
   phases. */
#define DEBUG 1

/* Enable this define if you want costly malloc debugging (buffer
   sentinel checking, block leak checking, etc). Recommended during
   debugging phases, but you should probably take it out before you
   start your final testing. */
#define KM_DBG

/* Enable this define if you want REALLY verbose debugging (print
   every time a block is allocated or freed). Only enable this if you
   are having some serious issues. */
// #define KM_DBG_VERBOSE

If you comment
#define DEBUG 1
and
#define KM_DBG

you'll stop kos extra debug.

Thanks buddy!

But for my project, this makes the application crash at startup!
I do believe this is related to the compiler version Im using...

[patbier]

If it crashes at startup, you may have a malloc / free problem

do you have possibility to use the debugger ? I tested the dcdev r4 toolchain and the gdb / insight works
It may give you the problem

To find malloc / free problem, you can also use cppcheck or splint, which are programs who checks errors in source code.