Denial

It's actually from the game I'm writing on the TI-99/4a. I cut it from an older map I was doing when I was still on the "big map" concept. I've switched to zones instead because it works way better on vintage system with slower drives.

Congratulations... the map looks awfully big... it's a real wonder... I wish you're planning a vic version...

Ivanhoe76 wrote:Congratulations... the map looks awfully big... it's a real wonder... I wish you're planning a vic version...

Yeah, I wanted something the size of Ultima 4, which was 256x256 tiles, which works out to 64k of map. (Although really in U4 there were only around 16 different types of tiles used on the actual map; most of the 256 tile count was for creatures and all their animation frames.)

My new approach is to store all maps into a 64k buffer file on each game disk. Each map is self-contained so only one load is necessary, which cuts down on overhead nicely. I can also do funky stuff like slant the maps for better coastlines. With four game disks I can have a game considerably larger than Ultima 4 or 5 in scale. Plus I'm not wasting tons of tile space on ocean tiles...

As for a VIC-20 version, it's certainly possible. Disk space is the same; the TI can get up to a 180k disk on the original controller. The TI actually only has around 32k of CPU memory (divided into an 8k and 24k block) and 16k of video-only memory (accessed through a narrow 8-bit bottleneck port), and no memory paging available on the native unit. I think the VIC-20 with all its RAM slots populated could easily match this.

I think the TI's got a few more colors and a higher resolution than the VIC-20, but a lot of my tile count (128 per set) are throwaways for artistic license; they could be discarded and gameplay kept identical. UI design would need a few adjustments, but nothing insurmountable.

However, I'm coding in TMS9900 assembly, a native 16-bit language with a very rich instruction set. I have 16 registers, no accumulator, and I can even do memory to memory operations. Another advantage is having unsigned multiply/divide operators, which allow me to do these operations in around 4-6 bytes. So a conversion would be a challenge, to say the least.

Adamantyr

That's rather an impressive map, lots of attention to detail ... you don't happen to study (or having studied) geology? Like how the rivers flow and mountain chains mark watersheds.

However, I'm coding in TMS9900 assembly,

In that regard, the TMS9900 and 65xx are more similar than you might think:

I have 16 registers, ...

... including stack-pointer, and program counter, which are actually stored in memory. There's a single internal register that points to the register set - useful for fast context switches.

The 6502 can be regarded as having 256 registers, or 128 16-bit address registers, in much the same way. The first 256 bytes of memory (the "zeropage") can be accessed with a short 1-byte address field in many instructions. The accumulator really only acts as quick dispatch/scratch register for memory contents. There are two 8-bit index registers (X and Y), where X often is used as counter, and Y as address offset.

... no accumulator, and I can even do memory to memory operations ...

On the 65xx I can always write something like 'LDA $1234:STA $2345', or 'LDA ($12),Y:STA ($34),Y' which support any combination of absolute, indexed, and indirect addressing modes, and transfer 1 byte, within 4-6 bytes.

... Another advantage is having unsigned multiply/divide operators, ...

A case for two sub-routines operating on zeropage operands. Callable with a 3-byte JSR instruction.

How big is the source code of your program? ... ...

Greetings,

Michael

Mike wrote:... including stack-pointer, and program counter, which are actually stored in memory. There's a single internal register that points to the register set - useful for fast context switches.

The 6502 can be regarded as having 256 registers, or 128 16-bit address registers, in much the same way. The first 256 bytes of memory (the "zeropage") can be accessed with a short 1-byte address field in many instructions. The accumulator really only acts as quick dispatch/scratch register for memory contents. There are two 8-bit index registers (X and Y), where X often is used as counter, and Y as address offset.

On the 65xx I can always write something like 'LDA $1234:STA $2345', or 'LDA ($12),Y:STA ($34),Y' which support any combination of absolute, indexed, and indirect addressing modes, and transfer 1 byte, within 4-6 bytes.

A case for two sub-routines operating on zeropage operands. Callable with a 3-byte JSR instruction.

How big is the source code of your program?

I see you know your stuff on architecture, very cool.

At the moment, since it's a work in progress, I don't have a total size, but I expect to have around 24k of code-space and 8k of data-space, not including the 16k in the video memory which besides screen and sprites is used to store graphic data and act as disk file I/O buffer space.

If I recall, the VIC-20's video memory is mapped into the address space? (which means it's probably way faster than the TI, which can manage around 1000 bytes in 1/60 of a second if it's doing a linear access.)

Adamantyr

Kweepa wrote:Wow, those are hideous!
From what I've seen yours are better already.

I like them for some weird reason. The pic of the dragon is pretty good, though. When I was contemplating whether or not I should make portraits of the monsters (because there was a lack of multi-color editing software beyond a 4x8 canvas), I kind of used the images of Wizardry as motivation. My game, although will be for the VIC-20, will have to compete with many CRPG's from the past, and I think that I should at least try to match if not exceed what was done previously.

As for adamantyr's map--all I've got to say is, wow. All I've done for my map so far is to create a general outline on a napkin. But looking at his map has given me quite a few ideas (such as using different types of tiles for water--I can see now how they add to the map's aesthetic value.).

Hey, some of you experts should convert adamantyr's game for the VIC-20 That way, I don't have to work so hard finishing my game, lol--kidding of course. I'd offer to do it (convert the game) myself, but I'm practically a 6502 n00b making his first 100% ML program.

But I'm determined as ever to finish my game no matter what. I always make sure to take the time to do a little bit of progress every day--even if it's just to design a 20x40 monster's portrait.

Here's another teaser from my upcoming game, critique and enjoy as much as you like:

Mike wrote:That's rather an impressive map, lots of attention to detail ... you don't happen to study (or having studied) geology? Like how the rivers flow and mountain chains mark watersheds.

Ghislain wrote:As for adamantyr's map--all I've got to say is, wow. All I've done for my map so far is to create a general outline on a napkin. But looking at his map has given me quite a few ideas (such as using different types of tiles for water--I can see now how they add to the map's aesthetic value.).

Thanks. The rivers actually DO flow via animation, thanks to interrupts. I used to have lava rivers as well (as you can see on the map) but I ended up dropping them... I think I was influenced by Revenge of the Sith on that one. I ended up replacing them with waterfalls instead, which are much more common and enjoyable.

I'll probably put together a "new" world map for the current structure, but it will be very interesting, as technically there will be gaps and empty areas that you can never reach that I'll have to fill in with other things to make it a cohesive whole. You'll probably really notice the square borders on it too, but oh well...

I found while I was placing tiles that it having the same tile over and over tends to create a "square" effect. The best solution I found was to have two types of each given tile, grass, mountain, hill, etc. By scattering the two in a chaotic fashion you can break up the squareness appearance and give it a more "real" look.

I should add, though, that a lot of the graphic work went out the window when I actually loaded stuff up on my authentic TI. The NTSC display muddied a great number of my tiles up, forcing me to go back and redo them for better clarity. Which is why it's always good to run off-emulator, or find an emulator that does NTSC simulation.

Adamantyr

adamantyr wrote:Thanks. The rivers actually DO flow via animation, thanks to interrupts. I used to have lava rivers as well (as you can see on the map) but I ended up dropping them... I think I was influenced by Revenge of the Sith on that one. I ended up replacing them with waterfalls instead, which are much more common and enjoyable.

I'll probably put together a "new" world map for the current structure, but it will be very interesting, as technically there will be gaps and empty areas that you can never reach that I'll have to fill in with other things to make it a cohesive whole. You'll probably really notice the square borders on it too, but oh well...

I was thinking about putting in rivers of magma and lava the other day and I'll definitely put that in there. Since you're abandoning your old map, can I steal yours? Well, not the whole thing, but I'll be embedding castles and cities with the natural terrain which is a spectacular visual effect.

I found while I was placing tiles that it having the same tile over and over tends to create a "square" effect. The best solution I found was to have two types of each given tile, grass, mountain, hill, etc. By scattering the two in a chaotic fashion you can break up the squareness appearance and give it a more "real" look.

Having 16 different types of tile in my game, I might not be able to pull that off? Do you compress the map in your game?

I should add, though, that a lot of the graphic work went out the window when I actually loaded stuff up on my authentic TI. The NTSC display muddied a great number of my tiles up, forcing me to go back and redo them for better clarity. Which is why it's always good to run off-emulator, or find an emulator that does NTSC simulation.

I'm fortunate that the VIC-20 has a pretty good video chip--you simply store information on the screen and it's guaranteed to be drawn over and over again 60 times per second without any more intervention by the programmer, I'm not familiar at all with the TI-99 but I did read the Atari 2600 programmer's manual a few years ago and with that machine, the programmer is expected to redraw the graphics 60 times a second. If Commodore land, you just have to store the information once in video memory (which is part of the main memory) once.

I believe the 2600 could use a frame buffer too if it had enough RAM. The 128 bytes built-in won't come a long way, but then again the 256 bytes built into an unexpanded TI-99/4(A) isn't much either (not counting the 16K VDP memory also used by its Basic). When Adamantyr writes 8+24K CPU memory it must be an expanded machine? Compare to the VIC-20 which has 5.5K RAM shared between CPU and VIC chip.

By the way, you know there is at least one brand of computers and video games combining the TMS graphics chip with the 6502 CPU? I mean if you would go bold in converting your RPG.

Love the graphic of the Beholder monster. The Beholder was one of the best monsters from the original Dungeons & Dragons. Any RPG trying to adhere to the format of the early 80s just wouldn't be complete without it!

ral-clan wrote:Love the graphic of the Beholder monster. The Beholder was one of the best monsters from the original Dungeons & Dragons. Any RPG trying to adhere to the format of the early 80s just wouldn't be complete without it!

Thanks, I had a lot of fun drawing it. I must have spent an hour making 4 different versions--they were all great but I chose this one because it had very little empty space.

Since I plan to 'sell' my game, there may be legal difficulties in using the 'Beholder' name as it is a registered creation of TSR (now Wizards of the Coast). I doubt that they would care if a small vanity project like this was using the name, but I might give it a different synonym or something to that effect.

if Futurama could have a beholder in their show, and the game DOOM, also has a beholder -type creature, I am sure no one is going to bug you about having them in your game.

Ghislain wrote:there may be legal difficulties in using the 'Beholder' name as it is a registered creation of TSR (now Wizards of the Coast). I doubt that they would care if a small vanity project like this was using the name, but I might give it a different synonym or something to that effect.

Beholders were used in Ultima, weren't they. But they renamed them.....I can't remember to what: "Gazer" or something?

ral-clan wrote:Beholders were used in Ultima, weren't they. But they renamed them.....I can't remember to what: "Gazer" or something?

That's the reason why other RPGs (and other media such as Futurama) are able to use 'beholders' -- they give them different names. Kind of like those PAC-MAN clones that were given different names (JELLY MONSTERS, MUNCHY, etc).

I'm thinking of using a different name other than BEHOLDER to keep with that tradition--sort of as a wink and a nod. D&D uses HALFLING instead of HOBBIT, and ULTIMA 1 uses BOBBIT instead of HOBBIT. But then again, I'll just use the original names.

Does anyone know if the ROPER is a registered D&D trademark?

Speaking of Futurama, that roper (great graphic) looks a lot like the blob creature!

http://images1.wikia.nocookie.net/en.fu ... G_Blob.jpg

Here is a front page of a science-fiction novel featuring a Beholder-like creature named 'Unklaich'. The novel had been published first in 1966:



The subtitle reads: 'The uncanny [creature] from Yakkath subdues them - and they become traitors of Terra ...'

This article gives a short description (in German only - the Babelfish translation is not that good): Perrypedia - Perry Rhodan - Raumaufklärer 008

Greetings,

Michael