JamesD

Hmmmm.... inventory. That presents a problem. In the OO way of doing things anyway. If you delete and replace the objects with a new level, then what happens to the object routines for items in the inventory? That implies common routines for these items within the main code or in all levels. Either way it requires some planning. Possibly a mix of both. I say keep the first 16(32?) items for inventory and they call fixed routines by default. Empty, inventory full (until you get stronger except the last location which is always pointed to inventory full routine) or the item routines. The rest can be random or loaded as a level (which is more Diablo like). However, at this stage there needs to be a list of what needs to be implemented. Ok, call it a wish list and decide what is a must and what is reserved for available memory. Store,blacksmite,mage shop... level size (um, free RAM?) Level generator, level loader... save game, load game... All this stuff impacts the oject *if* that is in fact the direction you'd like to take. What are the limits on the items that can be moved to inventory and how many can you carry based on weight... what is the max you can carry no matter how strong you are.... that sort of thing. A simple design doc/spec at least so the code can be designed to match. BTW, for large memory machines like the 130XE the objects could even lie in different memory pages and you add another page to the hi lo pointer ones for which page it's on and set it in the call routine. Takes the guesswork out of that completely.

Ok, just looked at it again and 8 bit registers more that double the code size.

The stupid 8 bit index registers probably double the number of instructions needed over the 6809/65816 cpus.

ONLY 60+ clock cycles per call!

For 256 items you can use 2 pages. Use one for high address bytes and the other for low address bytes. only modified code below ; get the address to the object and put it in tempaddress lda itemindexarray,x ; load the index for the item. tax lda objectarrayhi,x ; get the pointer to the object sta <tempaddress lda objectarraylo,x ; get the pointer to the object sta >tempaddress If the index has already been loaded before the call it's just: ; get the address to the object and put it in tempaddress lda objectarrayhi,x ; get the pointer to the object sta <tempaddress lda objectarraylo,x ; get the pointer to the object sta >tempaddress <edit> removed < and > from objectarrayhi and objectarraylo

<looking around for the spanish inquisition>

That's the whole reason I suggested lists in the first place. But my idea was a more object oriented approach where you call routines within the objects at fixed offsets from the base of the object. Then the main routine doesn't have to know how to deal with everything. An array of indexes to an array of pointers to objects... each object starting with a table of pointers to function calls. Awwwww.... the 6502 can do that easy! lets see... I hope I have the stack byte order and <> stuff right and I haven't used the 6502 in years but here goes... ; x contains the array index of the item ; y contains the offset to the routine to call in the object ; a contains parameter for call? ; call a routine within an object ; push the return address for the rts from the object call sta temp lda #<continue pha lda #>continue pha ; get the address to the object and put it in tempaddress lda itemindexarray,x ; load the index for the item. asl ; multipy the index by 2 (pointers are 2 bytes) tax ; put it in x lda <objectarray,x ; get the pointer to the object sta <tempaddress inx lda >objectarray,x ; get the pointer to the object sta >tempaddress ; now use pointer to get object routine pointer lda (tempaddress),y ;load the hi byte of the address to call pha iny lda (tempaddress),y ;load the lo byte of the address to call pha lda temp rts ;does a jsr with return address of continue: continue: See... only a few clock cycles to call objects in 6502 assembler! Actually, that's not exactly what I intended but that's only slightly faster.... I think.

Are you sure it missed? I dunno... Allllll right buddy... them's fightin words!!!! Pute up you dukes... come on....

LOL... I was kinda tired when I read yours and just went huh???

Don't store the pointers in the vram. Store an array index and have an array of pointers. If the term "list" bothers you try thinking array. List tends to bring up ideas of linked lists and such... not at all what I intended. The short list I described could actually be an array of indexes into the main array and would be small enough to fin in page 0 easy. 16 items = 16 bytes. Then the large array is pointers.

I guess we are making progress. Young man? Wow! THANK YOU! I might just be older than you though. I got my first programming gig in 1981. You object to my use of "argument"? I assure you my use of the word is correct and no swearing, etc... was implied. Definitions of argument on the Web: 1. a fact or assertion offered as evidence that something is true; "it was a strong argument that his hypothesis was true" 2. controversy: a contentious speech act; a dispute where there is strong disagreement; "they were involved in a violent argument" 3. a discussion in which reasons are advanced for and against some proposition or proposal; "the argument over foreign aid goes on and on" See definitions #1 and #3.

My biggest complaint with Ti isn't the machine but the company. Later machines tried to prevent 3rd party games written in assembly. I really don't know the details but if you ever buy a Ti get the silver version. That was my understanding anyway.

Congratulations! Now you understand why I'm saying your game selection is biased! You can pick out crap titles for any machine and compare it to good ones on another and it gives a distorted picture. So glad you agree with me. The entire 3D argument started because you wanted to pick 1 class of games in a thread about best overal gaming computer.

Spector jumps up and down for the speccy ignoring all games that don't favor the speccy and then accuses me of not being objective. He picks out individual games that were bad on the C64 and ignores the hundreds of others that weren't. What a troll! Since the speccy is such an isometric master, why don't we compare versions of the most commonly ported isometric game on 8 bit platforms? Zaxxon! You can find most off of the main wiki for zaxon. Zaxxon Wiki Spectrum Zaxxon Tandy Color Computer Zaxxon This doesn't have all versions of Zaxxon compared but rated the C64 version the best of what they reviewed. The Many Faces of Zaxxon

The CoCo3 had great graphics. No sprites though.

Objective language? HAH! The speccy has no special hardware for sprites, the color system doesn't even have close to the flexibility of the other machines and has lower resolution. It also doesn't support customizable characters like the C64 and Atari (drawn by hardware not software). The first ones didn't even have a sound chip or a joystick port built in. As a general gaming system I'd say that ranks it behind the C64 and Atari for sure.

I think people were smart enough to figure out the poll meant Atari 8 bit computers in general.

Well, the same could be said for almost every other computer. There are games specific to each that take advantage of some feature of the original platform that gives it a certain feel that is almost impossible to duplicate unless you do a line by line translation of the code. Many ports were done without a complete line by line translation and they don't "feel" the same. On the other hand if a translation is too close to the original code you end up loosing possible improvements for other platforms. But then some ports end up surpassing the original because the author does take advantage of some feature of a different maching. It almost always comes back to who was writing it..

As opposed to you. Never even owned a C64 and I don't really care one way or the other. I just think a lot of the ways the two machines are being compared here is pretty biased. (go figure) Speccy owners focus on a 3D games and discount the sprite & collision detection or character generation capabilities of the C64 but I'll bet every Speccy owner had a bunch of sprite oriented games in their collection as a kid. Should I go through the top games lists for the Speccy and point out how many were sprite oriented vs 3D? Each machine has it's advantages and saying one or the other is better depends on what you are doing. Even within a specific area you can't make an assumption that one or the other is better based on a single game because you don't know how the game was implemented and if it's a fair comparison.

Yeah, sure... let people assign a few initial points. I know pleanty of people that get a kick out of building a character and it shouldn't be too difficult. If you want to get fancy you might create a few base character classes with a standard points distrobution. Eventually you could limit what items can be wielded and how their points can be assigned. That's more Diablo 2 though. One thing I don't see in the source is any reference to weight or space. All objects have a weight and the stronger you are the more weight you can carry. How much space you have to carry items is another limiting factor. That would imply keeping an inventory and a running weight total. The space limit could be implemented with a simple item size (how many boxes it takes up) and you have a total number of boxes. As you pick up items you subtract the size from the total and when the size is greater than the total you have to drop an item or you can't pick up the new one. Oh, and what about Mana? Gee, aren't you glad I thought of that? LOL I'll look a little closer at the code once I get a little more time. PM'd you.

Translation: You are more interested in a comparison which favors your favorite machine. Just having to support 16 bits in the math would be more than enough to slow the machine down. The only way you'd ever really be able to compare them head to head is with a large number of benchmarks designed so that they wouldn't favor one or the other across the board.

More frames on what? One game? NO! Too many variables. The speccy uses 1 bit / pixel and the X coordinate fits in 1 byte. ANY machine that has a 320 pixel wide display must us 2 bytes to represent the X axis. THE MATH ROUTINES MUST ACCOUNT FOR THIS UNLESS YOU TRIM THE DISPLAY AREA DOWN TO 256 PIXELS! If a version of the game for a different computer is using a display mode with more than 2 colors it must do much more work! 4 colors = 2 bits / pixel. 16 colors = 4 bits / pixel. The other machine is having to do more work than the Z80 in the Speccy. Even on the same CPU the difference between screen resolutions and graphics modes would make a big difference. You couldn't expect anything else.

Blame the artist that drew them or the programmer. Perhaps they turned it out in a hurry or didn't want it to look as good. There's no technical reason it couldn't be better.

Try asking here: Lemon64