Assembly may be longer and more tedious to program, but you have control and ability to optimize it for speed.
But, that's exactly my point - speed is precisely something that you absolutely do not need in turn-based combat. The delay between executing various commands during the combat phase will just become a part of the feeling/experience of the game.
- How many cycles do we have without any DLIs per frame ? Around 20,200 at 160x192, right ?
- ASM code handling all the stats/uprading/etc. would take, say, 50% of it - so - 10,000
- C code, and let's exaggarate here, would take 10x more, e.g. 100,000 but that's still just 5 frames out of 50
You can write a complex RPG logic in C during one weekend. How much of that will you really write in 6502 ASM that will be 100% stable under all conditions ? The C logic, you can see all of it, in few pages of code. The ASM version will be easily 50+ pages of code.
Note, that when I'm talking about complex RPG logic, I mean at the very least the following (that I already implemented in past, in C++ for one of my old PC games, so I'm very much familiar with the debugging&testing effort of it all):
- 4 basic stats (speed, strength, accuracy, luck)
- combat stats equation (health, armor, level, damage)
- non-linear experience table
- game difficulty adjusting all damage equations
- static item stats modifiers (e.g. speed+2, accuracy - 1)
- time-based modifiers (e.g. spells: strength-4 for 30 seconds)
- randomizers that adjust the range of damage, so it isn't 100% of the time constant, but varies, ever so slightly
- proper full equations for handling armor (and no, I don't mean just coefficient here) taking damage
- special skills that build up (have a separate experience bar) and give you special attack
- Weapon/Item name generator using randomized adjectives, nouns (e.g. "Bastardized Hammer Of Tranquility")
- Enemy name generator using scheme above
- Enemy's weapon/armor/skills random generator
- Randomized (but guaranteed range) Enchantments of items
- Item equipment requirement conditions and kicking off equipped items at run-time once the time-based modifiers elapse
- scrolling inventory handling sorting of all items taking up 1x1, 2x2, 2x3, 3x3, 3x4 space on the grid
- unlocking more inventory space, once sufficiently leveled up
- Crate Item generator that fills the crate with items based on your current level (and that includes items outside of range, but just very few and/or none)
Could you implement the logic above in ASM in, say, two months ? Sure you could. I just don't understand the point of wasting your time on something that needs no performance in a turn-based game.
But I am looking at the ideal of the 3D Dungeon view, then go to another screen for the turned based combat.
I've switched to jag coding from 6502 few months back, but in my next 6502 coding spree (I should be receiving my EclaireXl board soon - though at the moment very busy with jag and other stuff), I will integrate the ultrafast 8-bit transformations with the clipping. Now, I had the clipping before, but it was 16-bit and that's much slower.
Technically, if the game was screen-based, e.g. no clipping required, we could use even current 6502 engine. Especially for static screen-based game, we could have some really complex 3D flatshaded scenes (not just a raycasting dungeon - I'm talking generic 3D meshes here, imported from 3dsmax).
While I definitely will sell carts of my game on jag, I'm not sure I feel the same way for A800. I presume your motivation is commercial or no ?