JamesD
-
Content Count
8,998 -
Joined
-
Last visited
-
Days Won
6
Posts posted by JamesD
-
-
james, thanks for your info. but keep in mind that the atari has not unlimited horse power to handle that... i doubt he can do this all in a nice speed. as i said earlier i am not sure how many enemies can be handled at once...
this is not gauntlet wth a lot of enemies on screen as we have a lot more stats to handle and to calculate each frame.
if we are just able to handle 4 enemies than we might handle each one separatly. but i like the list approach. but again its an 8bit cpu and unfortunatly we can just move 8bits per 2 cycles...
The Atari clock is what? 1.7Mhz for 1.7 million clocks/sec? Subtract some cycles stolen for graphics or whatever and there should still be over 1.5 millions cycles/sec available. 1,500,000 / 60 (for NTSC) = 25,000 cycles / frame for NTSC and 30,000 for PAL. You have some room there if you use it wisely.
You are still prototyping in BASIC so you aren't seeing that speed. Compiled Basic is probably making a lot of ROM calls so it's nowhere near the speed of other compiled languages.
The biggest problem with BASIC is it's lack of ability to deal with structures and pointers. Something the method I'm suggesting would depend on.
cc65 would be better but generating code for the 6502 is tough so I'd use assembly for the innermost loops.
Scanning the short list is pretty quick really.
Can the current character move yet?
Yes, call the move routine which just sets the new location for the character. Reset the move counter.
No, decrement the counter.
Can the current character attack (distance less than min attack distanc) and (time between attacks counter <= 0)
if yes, reset counter, set up display to use attack and update character stats
No, decrement the counter
if character animation in progress and count between cells <= 0 then advance to next cell and reset counter
No, decrement counter
If you keep track of what characters change position then the draw routine only has to update those characters.
Stats should be the least of your problems. The scrolling and any memory moves for cell animation will probably occupy the majority of your clock cycles.
If you find the stats calculations are taking too many cycles then take a step back and look for another way.
Limit the number of calculations in the main loop by precalculating everything and simplify the calculations you have to do.
The beginning stats of each baddie are precalculated at the creation of the level and stored in it's data structure. This also contains precalculated vales related to player interaction.
Some games don't increase a player's stats until a kill takes place. You only get credit for a kill, not just fighting. This reduces the number of times you need to update most of the player's stats and when they are updated the info just comes from the data structure of the dead baddie and is just added.
The chance of hitting a character is determined with a formula involving player level, armor, baddie level, etc... but those are pre-calculated and stored with the baddies and only updated when the player stats change such as a kill, level up or weapon & armor changes.
Something like this:
(chance of player hitting me = (player level - my level) * level difference compensation - my special armor points + player special weapon points)
(chance of me hitting player = (my level - player level) * level difference compensation - player special armor points + my special weapon points)
The range for the random number generator is already calculated so when attacking a character you just generate the random number with that range and see if it matches what you want for a hit.
Do the random... if no match it's a miss and you're done.
If it's a match then it's a hit and you need to subtract the base hitpoints of the weapon from the character, then generate a random number based on the precalculated range associated with your weapon and subtract the result.
(If a 'Dark Sword of Death' causes 60-70 points damage it means 60 base and 10 random)
(monster hit points -= player weapon damage base + random(player weapon damage range) - monster armor compensation)
Since hit rate of characters should be regulated this doesn't take place more than 1 or 2 times per second, per character. That's probably less than 10 times / sec on average.
-
i am just back from the games convention... it seems that RPG are one of the most covered genres...
but back to the enemy engine.i just implemented a simple hunt algorithm because it is simple and i could mess around with the player routines first. as i said... there are a lof of sub-engines in diablo which you dont "see" on the first look.
In Diablo and most other RPGs there's a line of sight and distance issue.
This actually makes your job easier and faster.
I'm not sure you want help but here's a possible way to implement this.
Keep two lists. One for close enemies and one for distant ones.
Scan the close object list for enemies that are no longer in range.
If they aren't test to see if that enemy will continue to follow or not and if not, move them to the long list.
Scan the distant one to find enemies within range and move them to the short list.
You can sort it by distance if you like to make it faster.
Any enemies within the minimum attack distance and line of sight (optional) are moved to the short list. Then the distance to the next closest enemy is calculated for testing. Your character must move at least that distance from the current location before you need to scan the long enemy list again.
The short list is used to update enemies on the screen by calling each routine associated with that enemy for it's logic. That way different enemies can be given unique behavior and speed. It can also track it's own timer to know whether or not it has sat long enough to move. A bonus of this is that an attack can stun a character simply by increasing the timer.
Killed enemies are removed from the short list simply by pointing it to the routine that continues to the next location.
Distance is pretty easy since it could be as simple as abs(difference in x) plus abs(difference in y).
I haven't written 6502 code in a long time but an indexed page 0 table might be able to handle the short list of enemy pointers.
It depends on how many bad guys are chasing you. I suppose you could limit it and then do a scan of the long list once when an enemy dies to see if another one can take it's place. In that case a sorted long list makes it easier since you just fill the short list with the closest baddies in range.
Obviously sprite or player missile limitations will dictate how you do a lot of this. It's easier for bitmapped graphics since you don't have those limits.
To compensate and prevent too many baddies from following you to another group of baddies you'll have to make baddies be persistant so they have to be killed before you move on.
-
Call me an optimist, but I don’t believe the FB3 project is dead. I’ve been looking at a lot of the old postings on this forum, and I noticed that if a project is dropped there is normally a confirmation from somebody close to the project. I have not seen that confirmation yet. (unless I missed something). I know that there was some kind of deadline that had to be met for production, but nobody close to the project has come out and said if it was met or not.
So I say “keep hope alive!”
Even if the project has been shelved for now it could be brought back in the future.
It doesn't need development, just production.
-
Curt Vendel wrote:
- 800 computer in a 5200 case
- function keys/buttons along under the silver strip for pause, select, keypad, etc...
- FB2 joystick usage
- Front SD card slot acting as D1:
- edge connector inside on board to solder an 800 cart connector to for legacy cartridge usage.
- Built in SIO2PC connection port for transferring to/from console
- footprint for SIO connector to be added
- footprint for ps/2 keyboard connector
- footprint for vga out
- Composite out
- Games included would've come on an SDcard
Sounds good. (sniff) I would have bought one (or two) for sure...
The SD interface, SIO2PC, PS/2 keyboard and VGA ports would make it worth it as an Atari 800 clone.
-
Wow, the game really starts to *feel* like diablo :-) can't wait to see further progress
I think the enemy logic would have to change before I'd say that but it's definately cool and an excellent start.
To feel more like Daiblo or most other action RPGs, the player must pass within a certain distance of enemies before they come after you. It looked like more enemies were just being sent as soon as one died. But then I didn't mess with it for long.
I think if you want another action RPG to borrow ideas from you should also look at Champions of Norrath for the PS2.
-
Hoping for a 5200/7800 combo is useless because, as I pointed out earlier, it's unrealistic to expect anyone to in effect shoehorn three video game systems into one unit; the platforms are totally different.
I wouldn't say such a beast is impossible.
The Flashback was designed in an FPGA in VHDL or Verilog so that helps a lot.
If they had working 5200 & 7800 designs what would be required is logic to switch around the memory map. That may sound complicated but actually just involves a more complex address decoding from the CPU.
Logic (devices) not used in one system's memory map are just kept from responding while ones that are get accessed.
Any shared devices like sound chips just respond at the required address.
Now, that doesn't mean the entire design would be practical.
If the CPUs don't share the same clock speed you may need multiple clocks or some sort of divider to provide each clock.
Any Digital to Analog stuff may vary significantly from one to the next enough to require different inputs or outputs.
Just designing the thing would require a larger FPGA and the final die would be larger and require more pins on the final part. Larger dies have a lower yield (good to bad ratio) and the cost for the custom chip jumps.
From a hardware hacker's point of view, some of the appeal of the C64 DTV is the fact that the system adds aditional hardware that never existed on the original system. The addition of a 256 color mode and blitter makes a whole new generation of games possible and you need that hardware to run them. Imagine what you could do just updating old games to have better graphics. Also, if properly designed you could run the system at a much higher clock speed.
-
An Intellivision handheld was available before the first Atari flashback.
http://www.intellivisionlives.com/
Edit:
By handheld it meant handheld that hooks to the TV.
-
Well, I was never a fan of the Atari 2600 so the other Flashbacks weren't appealing to me but I always thought the 800 was cool and now have 2 130XEs so I'd be much more interested in a Flashback based on the 800/5200.
I have one of the DTVs (C64 in a joystick) and thanks to it's hackability I think it's pretty cool. I'll use the one I have for games and once one of the fixed versions (fixed blitter, reflashable kernel, etc...) starts selling in the US I'll buy one just to build a computer out of.
If the Flashback 3 were as hackable I'd certainly buy one just for that if not a 2nd just for the built in games.
-
I don't know if it will work with this packaging but many companies use stickers for different systems and just cover over the default artwork.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Diablo-look a like possible on A8?
in Atari 8-Bit Computers
Posted
Understood and it sounds like you are on the right track. Work out the logic first and go from there.
BTW, by lists I just meant lists of pointers. If it were for a large machine or even a CPU that supported high level languages better I'd just use one and step through it until the current baddie was out of range instead of using a short list.
I figured the 2nd list would limit the number of moving characters and would fit in page zero to make for fast 6502 code. I could be wrong though... happens all the time!
Looks cool!