dcrpg-devel Mailing List for The Dreamcast RPG Engine
Status: Inactive
Brought to you by:
falkkin
Menu
▾
▴
dcrpg-devel — A mailing list for DCRPG developers.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(16) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Ivan W. <ban...@ya...> - 2002-02-14 17:09:30
|
Here I could buy DC Coders' Cable for US$25(exclude shipping), if anyone of you are interested in it, please reply. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
|
From: Colin M. <fa...@us...> - 2002-02-12 16:44:18
|
As some of you know, I recently purchased a DC Coders Cable from lik-sang.com, with UPS Express shipping. I've been waiting for it to arrive for nearly two weeks now, and finally e-mailed their customer service folks to ask what was up. Here's the response I got: "Thank you for your inquiry. We sincerely apologize for any inconvenience caused by this matter. Our system indicates this package has been denied entry into the US by US customs authorities due to the DIGITAL MILLENNIUM COPYRIGHT ACT. The shipper of record has been notified and the package will be returned to the shipper." In other words, US copyright law apparently prevents import of the DC Coders' Cable. This shouldn't be an issue for any developers outside the States whose governments have not (yet) implemented a version of the DMCA; however, this means that it'll be even longer before I'm able to contribute working DC code. I also hope lik-sang.com at least has the decency to give me my money back. - Colin |
|
From: Colin M. <fa...@us...> - 2002-02-07 07:37:02
|
I've started an IRC channel on the server irc.openprojects.net, and thrown a bot on it. The channel name is (unsurprisingly) #dcrpg. This could be useful as a place where IRC-savvy users can get quick answers to questions, or a place where a bunch of us can get together at once and collaborate. On the other hand, there's a decent chance it'll end up being useless :) Anyhow, just thought I'd let everyone know. - Colin |
|
From: Ivan W. <ban...@ya...> - 2002-02-07 00:55:11
|
Is there any dedicated surface for page flipping/temp, or all of the graphic must be placed in the 8MB? ----- Original Message ----- From: "Colin McMillen" <fa...@us...> To: <dcr...@li...> Sent: Wednesday, February 06, 2002 4:00 PM Subject: Re: [dcrpg-devel] Memory Question > > In this space we must fit: > > -the engine > > -the data (NPC(s), QUEST(s), PC(s), MONSTER(s), GRAPHIC(s)...) > > Keep in mind that a lot of this data (graphics, monsters, etc) can be put on > CD and only loaded when it's needed. I expect that most of the memory usage > will be taken up as map data, so I would probably go for maps of at least 2MB > (if not bigger). > > At 16 bits/tile, plus some overhead, this allows for a 1024x1024 map in the 2 > MB of memory. (pretty big, FF1 was 256x256). > > Assume 1 MB for KOS itself (I don't believe it's nearly that big, but might > eventually become so in the future). > > Assume another 2 MB for the engine itself (much likely it'll be much smaller > than that, but...) > > This gives ~3 MB of space left for whatever sounds, images, etc. need to be > loaded at any given point, and fudge space in case our engine / maps grow > larger than we expect. > > - Colin > > > _______________________________________________ > dcrpg-devel mailing list > dcr...@li... > https://lists.sourceforge.net/lists/listinfo/dcrpg-devel _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
|
From: Colin M. <fa...@us...> - 2002-02-06 21:06:23
|
On Wednesday 06 February 2002 11:29 am, Miles Raymond wrote: > Yeah... I really don't like (actually more like hate) the way this list > replies... =( Hitting "Reply To All" or "Group Reply" in your e-mail client should reply both to the list and to the original author of the post. That's probably the best way to reply. - Colin |
|
From: Miles R. <reu...@ya...> - 2002-02-06 17:30:42
|
Yeah... I really don't like (actually more like hate) the way this list replies... =( -Miles Raymond EML: m_r...@bi... AIM: Killer2Ray ICQ: 13217756 IRC: Killer2 WWW: http://www.bigfoot.com/~m_rayman ----- Original Message ----- From: "Colin McMillen" <fa...@us...> To: <dcr...@li...> Sent: Wednesday, February 06, 2002 10:16 AM Subject: Fwd: Re: [dcrpg-devel] Memory Question > This got accidentally sent to me instead of to the mailing list, I believe. > Looks like we have more space that I'd thought. > > - Colin > > ---------- Forwarded Message ---------- > > Subject: Re: [dcrpg-devel] Memory Question > Date: Wed, 6 Feb 2002 07:56:12 -0600 > From: "Miles Raymond" <reu...@ya...> > To: "Colin McMillen" <fa...@us...> > > Actually... according to http://www.boob.co.uk/docs/Dreamcast_memory.txt the > DC has a total of 16MB main mem + 2MB sound RAM + 8MB video = 26MB RAM > usable. > > Any sound data can be loaded directly off of the CD into sound RAM. The > whole sprite part of an uncompressed 512x512 map could be loaded directly > off of the CD into video RAM. That leaves the entire 16MB of RAM for the > program and tilemap data. > > -Miles Raymond EML: m_r...@bi... > AIM: Killer2Ray ICQ: 13217756 IRC: Killer2 > WWW: http://www.bigfoot.com/~m_rayman |
|
From: Colin M. <fa...@us...> - 2002-02-06 16:16:25
|
This got accidentally sent to me instead of to the mailing list, I believe. Looks like we have more space that I'd thought. - Colin ---------- Forwarded Message ---------- Subject: Re: [dcrpg-devel] Memory Question Date: Wed, 6 Feb 2002 07:56:12 -0600 From: "Miles Raymond" <reu...@ya...> To: "Colin McMillen" <fa...@us...> Actually... according to http://www.boob.co.uk/docs/Dreamcast_memory.txt the DC has a total of 16MB main mem + 2MB sound RAM + 8MB video = 26MB RAM usable. Any sound data can be loaded directly off of the CD into sound RAM. The whole sprite part of an uncompressed 512x512 map could be loaded directly off of the CD into video RAM. That leaves the entire 16MB of RAM for the program and tilemap data. -Miles Raymond EML: m_r...@bi... AIM: Killer2Ray ICQ: 13217756 IRC: Killer2 WWW: http://www.bigfoot.com/~m_rayman |
|
From: Colin M. <fa...@us...> - 2002-02-06 08:00:25
|
> In this space we must fit: > -the engine > -the data (NPC(s), QUEST(s), PC(s), MONSTER(s), GRAPHIC(s)...) Keep in mind that a lot of this data (graphics, monsters, etc) can be put on CD and only loaded when it's needed. I expect that most of the memory usage will be taken up as map data, so I would probably go for maps of at least 2MB (if not bigger). At 16 bits/tile, plus some overhead, this allows for a 1024x1024 map in the 2 MB of memory. (pretty big, FF1 was 256x256). Assume 1 MB for KOS itself (I don't believe it's nearly that big, but might eventually become so in the future). Assume another 2 MB for the engine itself (much likely it'll be much smaller than that, but...) This gives ~3 MB of space left for whatever sounds, images, etc. need to be loaded at any given point, and fudge space in case our engine / maps grow larger than we expect. - Colin |
|
From: Atonkelton <Ato...@gm...> - 2002-02-06 07:24:33
|
As I recall the DC has 8MB of RAM. In this space we must fit: -the engine -the data (NPC(s), QUEST(s), PC(s), MONSTER(s), GRAPHIC(s)...) So, how big can the maps actually be? Or how small can we make the engine? I tried to calc it roughly, but with no luck (too much variables). What do we aim at? |
|
From: Miles R. <reu...@ya...> - 2002-02-05 18:14:25
|
No prob! Hehe, it seems I did my math incorrectly as well... it would be
32bits or 4bytes as you say, not my previous 16bits or 2 bytes. Colin wants
to aim for 16bits if we don't use any of that extra space that 7 or 8bit IDs
will give (128 or 256 IDs).
I guess I should rewrite it as:
struct tile16
{
unsigned int walkable : 1; //0 not walk, 1, walkable
unsigned int front : 1; //0 back, 1 front
unsigned int monster_info : 3; //monster id(s)
unsigned int event_id : 3; //event id *
unsigned int fg_sprite_id : 4; //foreground sprite id *
unsigned int bg_sprite_id : 4; //background sprite id *
} tile16;
struct tile32
{
unsigned int walkable : 1; //0 not walk, 1, walkable
unsigned int front : 1; //0 back, 1 front
unsigned int monster_info : 7; //monster id(s)
unsigned int event_id : 7; //event id *
unsigned int fg_sprite_id : 8; //foreground sprite id *
unsigned int bg_sprite_id : 8; //background sprite id *
} tile32;
-Miles Raymond EML: m_r...@bi...
AIM: Killer2Ray ICQ: 13217756 IRC: Killer2
WWW: http://www.bigfoot.com/~m_rayman
----- Original Message -----
From: "Dirk Leser" <dir...@gm...>
To: "Miles Raymond" <reu...@ya...>
Sent: Tuesday, February 05, 2002 11:22 AM
Subject: Re: [dcrpg-devel] DC RPG
> Sorry I ignored the ':' this makes 4 Bytes instead of my 24 Bytes
> Apologies...
|
|
From: Miles R. <reu...@ya...> - 2002-02-05 17:05:46
|
Why would this be struct be memory-intensive? It uses a bit-field so that each tile consists of 16bits or 2bytes. Maybe I'm just not understanding your suggestion... can you give an example code fragment which utilizes your proposal? -Miles Raymond EML: m_r...@bi... AIM: Killer2Ray ICQ: 13217756 IRC: Killer2 WWW: http://www.bigfoot.com/~m_rayman ----- Original Message ----- From: "Atonkelton" <Ato...@gm...> To: "Mailinglist" <dcr...@li...> Sent: Tuesday, February 05, 2002 10:51 AM Subject: Re: [dcrpg-devel] DC RPG > hi, > > I personally like the con-/destructor suggestion. It's more flexible. > So we're not bound with a particular map-layout (other than rectangular, > that is). > > I just played around with FF1 and Zelda (NES/SNES) they do not seem to have > wrap-around maps. But we could make that optional for our mappers. > > NOTE: > this structure can get pretty big, if used in big numbers > struct tile > { > unsigned int walkable : 1; //0 not walk, 1, walkable > unsigned int front : 1; //0 back, 1 front > unsigned int monster_info : 7; //monster id(s) > unsigned int event_id : 7; //event id * > unsigned int fg_sprite_id : 8; //foreground sprite id * > unsigned int bg_sprite_id : 8; //background sprite id * > } tile; > > I suggest putting boolean into a integer-value and then > AND or XOR them out -> little memory-friendlier. > > /* > Atonkelton <Ato...@gm...> > ICQ #7062663 > Please do not send any files larger than 512kb without request! > */ |
|
From: Atonkelton <Ato...@gm...> - 2002-02-05 16:51:49
|
hi,
I personally like the con-/destructor suggestion. It's more flexible.
So we're not bound with a particular map-layout (other than rectangular,
that is).
I just played around with FF1 and Zelda (NES/SNES) they do not seem to have
wrap-around maps. But we could make that optional for our mappers.
NOTE:
this structure can get pretty big, if used in big numbers
struct tile
{
unsigned int walkable : 1; //0 not walk, 1, walkable
unsigned int front : 1; //0 back, 1 front
unsigned int monster_info : 7; //monster id(s)
unsigned int event_id : 7; //event id *
unsigned int fg_sprite_id : 8; //foreground sprite id *
unsigned int bg_sprite_id : 8; //background sprite id *
} tile;
I suggest putting boolean into a integer-value and then
AND or XOR them out -> little memory-friendlier.
/*
Atonkelton <Ato...@gm...>
ICQ #7062663
Please do not send any files larger than 512kb without request!
*/
|
|
From: Miles R. <reu...@ya...> - 2002-02-04 20:55:01
|
That sounds a lot like C++ classes... maybe we should consider using C++?
So this is what I have so far for a tile:
//32bit tile structure
struct tile
{
unsigned int walkable : 1; //0 not walk, 1, walkable
unsigned int front : 1; //0 back, 1 front
unsigned int monster_info : 7; //monster id(s)
unsigned int event_id : 7; //event id *
unsigned int fg_sprite_id : 8; //foreground sprite id *
unsigned int bg_sprite_id : 8; //background sprite id *
} tile;
//* as defined in the map structure
This may be overkill... Maybe the tile structure should be nothing more
than what sprites are displayed... and the map structure more complex?
These are all just suggestions...
-Miles Raymond EML: m_r...@bi...
AIM: Killer2Ray ICQ: 13217756 IRC: Killer2
WWW: http://www.bigfoot.com/~m_rayman
----- Original Message -----
From: "Colin McMillen" <mcm...@tc...>
To: <dcr...@li...>
Sent: Monday, February 04, 2002 11:05 AM
Subject: Re: [dcrpg-devel] DC RPG
> > Well, this is as much as I know:
> > -I am assigned the map engine
> > -Colin is doing the fighting engine
> > -Dan is working on ... ? (I must have missed this)
>
> I don't know what Dan is working on either... I've not heard back from him
> recently. We have two new developers on the project (Atonkelton and
> banandgia2), and I don't know what they'd like to work on yet.
>
> > For start, are we just going to rip graphics from FF1 and use them? Or
are
> > we going to create our own?
>
> I actually have some "open-source" map tiles, donated by a guy who's done
> tiles for ZAngband... don't know what we'll do for other graphics; I don't
> feel good using ripped graphics of a copyrighted game, so we might just
use
> abstract shapes like colored rectangles to represent some things until we
get
> some real art.
>
> > And this may sound rediculous or obvious... but do we have a story plan?
>
> Not yet. RIght now I'm only interested in the engine, not the story. I
figure
> it'll be time to work on story once we have the engine in a workable
state.
>
> > Should we design the maps so that they wrap around?
>
> I think that should be a flag in the map struct itself -- some maps, like
a
> world map, should probably wrap around, while others, such as in-dungeon
or
> in-town maps, should not. Each map will probably have some global data in
it,
> in addition to the tile data, and we don't need to worry about being as
> sparse about the data for maps, as there'll only ever be one map loaded
into
> memory at a time.
>
> I'm picturing something like this (pseudo-C code):
>
> typedef struct map {
> int length, width;
> tile* tiles; // 2-d array will be filled in here
> int wraps; // 0 or 1
> char* name;
> // possibly more data as we need it
> } map;
>
> > Should we design a map size limit? If so, what should it be? (ie:
> > 512x512, 1024x1024, etc)
>
> I don't think we should build one in... the DC has 8 MB of memory (if i
> remember right) so we'd currently be unable to store anything larger than
> 1024x1024 in main memory at a time (assuming we keep to our design
criterion
> of ~64 bits/tile)... however that's no reason to build an arbitrary limit
in;
> maybe someone would rather have the map be 4096 x 128 for some reason, or
> whatever.
>
> What I'd do is make a map "constructor" that allocates a map, and a map
> "destructor" that deallocates it, something like this:
>
> map* map_new(int length, int width) {
> map* m = (map*) malloc(sizeof(map));
> m->length = length;
> m->width = width;
> m->tiles = (tile*) malloc(length * width * sizeof(tiles));
> // etc
> }
>
> void map_free(map* m) {
> free(m->tiles);
> free(m);
> m = NULL;
> }
>
> In general I'd like a "constructor" and "Destructor" like this for any
data
> structure that needs to malloc() memory; it'll make memory management much
> easier. (Memory leaks on the DC being quickly fatal, with only 8 MB of RAM
:))
>
> > Should we design the maps so that they HAVE to be a square matrix? Or a
> > matrix at all? Or maybe just a an array of arrays?
>
> I'd go with a rectangular matrix, as I don't see any need to have a
> non-rectangular, ragged map. However, any rectangle should work, not just
> squares.
>
> - Colin
|
|
From: Colin M. <mcm...@tc...> - 2002-02-04 17:05:48
|
> Well, this is as much as I know:
> -I am assigned the map engine
> -Colin is doing the fighting engine
> -Dan is working on ... ? (I must have missed this)
I don't know what Dan is working on either... I've not heard back from him
recently. We have two new developers on the project (Atonkelton and
banandgia2), and I don't know what they'd like to work on yet.
> For start, are we just going to rip graphics from FF1 and use them? Or are
> we going to create our own?
I actually have some "open-source" map tiles, donated by a guy who's done
tiles for ZAngband... don't know what we'll do for other graphics; I don't
feel good using ripped graphics of a copyrighted game, so we might just use
abstract shapes like colored rectangles to represent some things until we get
some real art.
> And this may sound rediculous or obvious... but do we have a story plan?
Not yet. RIght now I'm only interested in the engine, not the story. I figure
it'll be time to work on story once we have the engine in a workable state.
> Should we design the maps so that they wrap around?
I think that should be a flag in the map struct itself -- some maps, like a
world map, should probably wrap around, while others, such as in-dungeon or
in-town maps, should not. Each map will probably have some global data in it,
in addition to the tile data, and we don't need to worry about being as
sparse about the data for maps, as there'll only ever be one map loaded into
memory at a time.
I'm picturing something like this (pseudo-C code):
typedef struct map {
int length, width;
tile* tiles; // 2-d array will be filled in here
int wraps; // 0 or 1
char* name;
// possibly more data as we need it
} map;
> Should we design a map size limit? If so, what should it be? (ie:
> 512x512, 1024x1024, etc)
I don't think we should build one in... the DC has 8 MB of memory (if i
remember right) so we'd currently be unable to store anything larger than
1024x1024 in main memory at a time (assuming we keep to our design criterion
of ~64 bits/tile)... however that's no reason to build an arbitrary limit in;
maybe someone would rather have the map be 4096 x 128 for some reason, or
whatever.
What I'd do is make a map "constructor" that allocates a map, and a map
"destructor" that deallocates it, something like this:
map* map_new(int length, int width) {
map* m = (map*) malloc(sizeof(map));
m->length = length;
m->width = width;
m->tiles = (tile*) malloc(length * width * sizeof(tiles));
// etc
}
void map_free(map* m) {
free(m->tiles);
free(m);
m = NULL;
}
In general I'd like a "constructor" and "Destructor" like this for any data
structure that needs to malloc() memory; it'll make memory management much
easier. (Memory leaks on the DC being quickly fatal, with only 8 MB of RAM :))
> Should we design the maps so that they HAVE to be a square matrix? Or a
> matrix at all? Or maybe just a an array of arrays?
I'd go with a rectangular matrix, as I don't see any need to have a
non-rectangular, ragged map. However, any rectangle should work, not just
squares.
- Colin
|
|
From: Miles R. <reu...@ya...> - 2002-02-04 16:40:07
|
Should we design the maps so that they wrap around? Should we design a map size limit? If so, what should it be? (ie: 512x512, 1024x1024, etc) Should we design the maps so that they HAVE to be a square matrix? Or a matrix at all? Or maybe just a an array of arrays? ie: struct tile map1[height][length] //square (height==length) or rectangular matrix or hmm... don't know if this is quite right struct tile * map1[height] //array of pointers to arrays of tiles Maybe that is more trouble than it's worth, because we'd have to align them somehow... and it wouldn't be as easy to access them... map1[y][x] as opposed to *(*(map1[y])+x) or maybe someone can correct my forgotten C coding... Well, there's my current thoughts... -Miles Raymond EML: m_r...@bi... AIM: Killer2Ray ICQ: 13217756 IRC: Killer2 WWW: http://www.bigfoot.com/~m_rayman ----- Original Message ----- From: "Miles Raymond" <m_r...@bi...> To: <dcr...@li...> Sent: Monday, February 04, 2002 9:46 AM Subject: [dcrpg-devel] DC RPG > Well, this is as much as I know: > -I am assigned the map engine > -Colin is doing the fighting engine > -Dan is working on ... ? (I must have missed this) > > For start, are we just going to rip graphics from FF1 and use them? Or are > we going to create our own? > > And this may sound rediculous or obvious... but do we have a story plan? > > -Miles Raymond EML: m_r...@bi... > AIM: Killer2Ray ICQ: 13217756 IRC: Killer2 > WWW: http://www.bigfoot.com/~m_rayman |
|
From: Miles R. <m_r...@bi...> - 2002-02-04 15:46:44
|
Well, this is as much as I know: -I am assigned the map engine -Colin is doing the fighting engine -Dan is working on ... ? (I must have missed this) For start, are we just going to rip graphics from FF1 and use them? Or are we going to create our own? And this may sound rediculous or obvious... but do we have a story plan? -Miles Raymond EML: m_r...@bi... AIM: Killer2Ray ICQ: 13217756 IRC: Killer2 WWW: http://www.bigfoot.com/~m_rayman |
