Platform engine demo

[Arkhan]

damn, that nagawhore with the bow has a nice rack.

[MottZilla]

Nice to see some active PCE homebrew. So does C program code get good performance on the PCE? I know with SNES it's not a great idea and that you might get by on Genesis's 68000. PCE has a pretty fast 65xx family CPU so I'm guessing it should atleast be a good bit better than the SNES trying to run C compiled code. Basically what do you think is possible with C on PCE? Probably not crazy object heavy fast paced action? But say something with a reasonable amount of action going on, perhaps like what you'd see in a NES or SNES game? Just curious as C is handy though ASM in the 65xx family is no problem for me.

And what do you mean by Finite State Machine?

[nodtveidt]

http://en.wikipedia.org/wiki/Finite-state_machine

The existing C compilers for the PCE (HuC, cc65) aren't the best, but with clever programming techniques (and the occasional assembly boosts), you can do some really nice work. I've never done C on the SNES, but I would imagine that it isn't terribly good because the SNES CPU moves at a snail's pace. Tomatheous has stated that C on the Genesis should work out well because the 68000 is a good CPU for a C compiler.

[TheOldMan]

The existing C compilers for the PCE (HuC, cc65) aren't the best,

Awww.... You're being too nice ;-)

but with clever programming techniques (and the occasional assembly boosts),

Yeah. The way code is generated for arrays is deadly to speedy programs. I tend to make it work for one item
in C, then drop to assembler to make things work for multiple items.

C on the Genesis should work out well because the 68000 is a good CPU for a C compiler.

If it's anything like it's younger brother the 6809, it has one helpful feature the 65xx lacks - built in indirection. I know, you -can- do it on the turbo, but it would be so much nice to point to a table (with an offset in a register) and say "jsr [table,y]" to indirectly call the routine at entry Y in the table. On the 65xx, the address has to be in the zero-page, which means it has to be copied there somehow...and if you have to copy it, you might as well add in the index while doing it. It still drives me crazy trying to do state-based calls :-(

[nodtveidt]

Tomatheous mentioned something about optimizing code generation for array access, but I don't know if he ever messed with it or not.

[nodtveidt]

I released another prototype build, but it's on the Eponasoft website at http://www.eponasoft.com/ ... it has a couple of new features, mainly background parallax (see-through windows!) and water obscuring.

[spenoza]

It's pretty cool so far, though I think some of the physics could use a tweak. The character moves just quickly enough that precise control is a little hard. Also, jumping off of ropes and ladders has some odd behavior when you're at or near the top. Additionally, sound effects seem to lag the triggers by a bit much, so that if you're jumping a lot the landing sound plays when you're already up in the air from the second jump.

Impressed with some of the graphics, though, certainly.

[nodtveidt]

The sound effect lag is a known problem with certain emulators. I noticed it in Ootake. The problem doesn't seem to exist in Mednafen or Magic Engine. I'm not thrilled about how the jumping works, but now that it has Y-axis correction, it will be a lot easier to implement a better jump method. I can slow down walking... he does move a bit fast, I agree. The graphics aren't final; they're mostly ripped from RM2K tilesets. I'm currently in the market for a tile artist for this production.

Thanks for checking it out. I'm not sure how many more public prototypes I'm going to release of it though... maybe a few more.

[Vecanti]

 http://www.eponasoft.com/  has been down all day for me.  Hoping to test the latest soon.

EDIT:
Right after I wrote that is started working.  Great work.  The transparency (windows) seems to work in the X and Y axis at the same time?

[nodtveidt]

The data center had a DNS server failure... everything should be working now.

[Arkhan]

Nice to see some active PCE homebrew.

Slight hijack of thread:  Click the big banner in my signature, lol.  There is some other active stuff,

So does C program code get good performance on the PCE?

No. Not at all.  If you are making a game that isn't action packed like a shmup, it'll be just fine.  It's great for RPGs.   Anything that involves alot of things going on on screen at the same time, has problems.  HuC is pisspoor at generating certain things in assembly.   

Arrays being the big one, and lets be honest, who the hell doesn't use arrays for things in C? 

If you plan to do a homebrew and don't want to do Assembly, you better plan something simple otherwise, chances are you'll need to twiddle around with assembly within the C code to make it work good.  Insanity was done largely in C, but assembly was required to solve the problem of having no struct functionality, and the problem of array indexing being a disaster.  Sure Insanity isn't exactly action packed, but it is possible to have 10 robots, 10 enemy shots, You, and Your shot all on screen at the same time.  The collision checking then becomes a bit of a problem.   If there weren't so many possibilities of collisions, it would be alot simpler.   Platforming games, and RPGs seem to be two things that are C friendly.  Anything involving a ton of sprite collision checking, is not so good.

I suspect something like Keith Courage or even Bonk could be done entirely in C.

For Insanity though:
You have to check all 10 robots against all 10 robots plus you..  Thats 110 checks.
Then you check All 10 robots for wall collisions.  10 checks that are slow because the built in tile functions suck.
Then you check all 10 robot shots to all 10 robots plus you.  Thats another 110 checks.
Then you check the shots vs. walls, so 10 more slow checks...
and then your shot vs all 10 robots AND their shots (you can shoot their shots), so 20 checks.
along with you vs walls.

Alot of checking that needs to be done in one vsync.  Alot of array indexing would be used in C.  Inefficient array indexing.  Along with slow map tile checks.  Definitely not going to work out so good with the slow HuC stuff.  Go Go Gadget Assembly.

and yes the only old CPU that really manages C code well is the 68k.  The Amiga uses a 68k, and youd be amazed what you can do on that machine in C without ever having to touch assembly.   

Ecco the dolphin on Sega was written entirely in C.

[MottZilla]

Thanks. Exactly what I wanted to know. I'd heard before that 68000's design is pretty C/High level language friendly compared to the 65xx family atleast.

[nikdog]

It's pretty cool so far, though I think some of the physics could use a tweak.

Another thing I feel that could be done is to be a little forgiving on delayed jumping. I have defiantly gotten to the edge many of times and hit jump, only to fall to the ground in frustration. It may have been the emulator lagging. I should cross check it with mednafen just in case, and I may be the only one with this opinion.

[nodtveidt]

The interesting thing about collisions is that you don't have to process them all at once. You can easily delay some of them by a frame or two, shaving off hundreds of cycles per vsync. It's just one of the many ways around the flaws of HuC's code generator. However, the huge number of collisions that a game like Insanity requires simply isn't suited for arrays; you would only get decent performance by having individual variables for each entity and the expense of much larger code size. That is, of course, if you were to stick with straight HuC with no assembly-level modifications. As of right now, this platform engine is pure HuC, though it will get "the cleansing" eventually to maintain performance.

nikdog, I'm not quite sure what you're referring to...

[Arkhan]

The interesting thing about collisions is that you don't have to process them all at once. You can easily delay some of them by a frame or two, shaving off hundreds of cycles per vsync. It's just one of the many ways around the flaws of HuC's code generator. However, the huge number of collisions that a game like Insanity requires simply isn't suited for arrays; you would only get decent performance by having individual variables for each entity and the expense of much larger code size. That is, of course, if you were to stick with straight HuC with no assembly-level modifications. As of right now, this platform engine is pure HuC, though it will get "the cleansing" eventually to maintain performance.

Delaying collisions in a game that operates on a frame by frame basis for movement/ai won't work so good.  You'll have robots die and one will noticeably go first, and dealing with that many individual variables for that many things would just be obfriggingnoxious.

That's what DIY structs are for. 

If HuC had structs, shit would be alot frigging easier.