Artillery for Battles against C64 or Spectrum Fanboy's

[TMR]

Well allow me to get my razor blade so that we can split hairs together

Oh sorry, i didn't know that being accurate was only optional...

Do you have a video link?

Yup. It uses a character-based 80 by 192 pixel mode and the hardware sprits are expanded to match the pixel ratio. The mode doesn't work on early Atari 8-bits with a CTIA rather than a GTIA or some late models of XE due to a manufacturing fault in the hardware (i haven't replicated this despite trying to find a 65XE with the issue for testing).

[andycadley]

Was that game made to utilize what the c64s hardware can do best?

I believe it was slightly crippled to be at least feasible on an Atari 800XL, though TMR  can probably say for certain. I did consider a GX4000 version at one point, but the numbers just work ever so slightly against what the hardware can do best....

[TMR]

Was that game made to utilize what the c64s hardware can do best?

Not really no, it's just a simple budget-style shoot 'em up; the original code was even put together in a machine code monitor rather than an assembler, then converted and optimised later! That said, it scrolls at 50FPS and also only takes under 32K when executing, compressing to just shy of 16K.

The idea behind Edge Grinder was to produce a fairly generic shooter on the C64 and then "challenge" other coders to port it to their system of choice to see how they'd do it and what changes were made along the way; that's why there are only eight sprites, one level and the processor is essentially sat idle for the majority of the time.

I believe it was slightly crippled to be at least feasible on an Atari 800XL, though TMR  can probably say for certain.

i kept the number of enemy sprites on a scanline down to i think it was five at the behest of the Atari coders considering a port since they had a technique in mind that'd work if there weren't too many co-existing, but the overall "plan" was to just keep it simple to invite would-be porters.

[ivarf]

Not really no, it's just a simple budget-style shoot 'em up; the original code was even put together in a machine code monitor rather than an assembler, then converted and optimised later! That said, it scrolls at 50FPS and also only takes under 32K when executing, compressing to just shy of 16K.

The idea behind Edge Grinder was to produce a fairly generic shooter on the C64 and then "challenge" other coders to port it to their system of choice to see how they'd do it and what changes were made along the way; that's why there are only eight sprites, one level and the processor is essentially sat idle for the majority of the time.

i kept the number of enemy sprites on a scanline down to i think it was five at the behest of the Atari coders considering a port since they had a technique in mind that'd work if there weren't too many co-existing, but the overall "plan" was to just keep it simple to invite would-be porters.

Super Edge Grinder is a fantastic game on the CPC as scrolling scooter. Not many scrolling games are this smooth. In hindsight I wonder if it this kind of quality we should have expected back in the day if the coders knew the hardware and put in some effort, or is this game just exceptional on the CPC?

[robcfg]

Well, there were good coders back in the day for sure, but now, we have knowledge and time.


I think the problem is the whole 'industry' thing. Having 2 weeks to port, say... R-Type, wouldn't allow for something as the R-Type remake.

[FloppySoftware]

Well, there were good coders back in the day for sure, but now, we have knowledge and time.

... and new technology. Agreed.

We can create / edit our source code and resources, compile and test it in the same machine in few seconds, thanks to emulators, cross-compilers, powerfull machines, big hard drives, multi-tasking, etc.

Doing the same in "our beloved machine" is a pain.

[robcfg]

Amen to that, brother!

[||C|-|E||]

... and new technology. Agreed.

We can create / edit our source code and resources, compile and test it in the same machine in few seconds, thanks to emulators, cross-compilers, powerfull machines, big hard drives, multi-tasking, etc.

Doing the same in "our beloved machine" is a pain.

I can tell you, for sure, that it would have been completely impossible to develop Doomsday in the same way if I was not using the PC (and Dani Photoshop). In my case, compiling would take ages and editing a source that is almost 300KB would be pretty much impossible with a standard 6128  .

[TFM]

We can create / edit our source code and resources, compile and test it in the same machine in few seconds, thanks to emulators, cross-compilers, powerfull machines, big hard drives, multi-tasking, etc.

Doing the same in "our beloved machine" is a pain.

No, that's all the fun! 

... In my case, compiling would take ages and editing a source that is almost 300KB would be pretty much impossible with a standard 6128    .

I do that with Prowort (=German Protext for CP/M) and 444 KB RAM disc. No problem! 

[FloppySoftware]

Humm... a few days, someone was asking me about te (my small text editor). He told me that the compilation time with MESCC was around half an hour in his machine. 
I do the same in a couple of seconds in my PC and a CP/M emulator. 

[ivarf]

... and new technology. Agreed.

We can create / edit our source code and resources, compile and test it in the same machine in few seconds, thanks to emulators, cross-compilers, powerfull machines, big hard drives, multi-tasking, etc.

Doing the same in "our beloved machine" is a pain.

I was doing stuff like this at school in 1991, sure my engineering school in Norway wasn't the earliest of the adopters of this technology.

[TFM]

Humm... a few days, someone was asking me about te (my small text editor). He told me that the compilation time with MESCC was around half an hour in his machine. 
I do the same in a couple of seconds in my PC and a CP/M emulator. 

Well, then MESCC is really bad in compiling. Compare MAXAM and the new French assembler. For about 150 KB Z80 source MAXAM need about 10 minutes, and the French assembler does it in a small amount of seconds. It's all doable.


BTW: This was one of the main reasons for me to develop FutureOS - to have software which is that efficient, that new hardware is not needed. And I still stick to that. Using a CPC instead of an emulator is my true choice and I wouldn't like to have in any other way. 

[FloppySoftware]

I was doing stuff like this at school in 1991, sure my engineering school in Norway wasn't the earliest of the adopters of this technology.

I was talking about home computers.

In 1991, I was trying to compile Small-C (the father of MESCC) and after an hour of compilation and various ruunnnn-jasps-rouurrrns noises from the 3" floppy disk drive, the result was a syntax error found in the original source code.

As in my PCW I had only ED and RPED as text editors (not very suitable for the task), I left CP/M and booted LocoScript.

I inserted the source code in a empty LocoScript document, corrected the wrong character (yes, it was only one!), and saved the result as an ascii file.

Then, I left LocoScript and booted CP/M again.

I ran the compiler over the new source code, and after an hour of compilation and lot of graaaaoupp-jijijiriririrs-knowptrs noises, I had the result as an assembler source code file.

I ran the assembler (the good old Z80ASMUK from the CP/M UK Users Group), and after another hour of grrriinnds-jioopsstr-jijoustprr noises from the floppy disk drive, I had a hex file as a result.

Then, I ran the HEXCOM tool, and after twenty minutes of so of more graouuuurrr-jojopupmer-joush noises, I had AT LAST an executable COM file.

I was lucky, because my 180 Kb humble floppy disk was able to hold all the data.

I leave the details of debugging for another time. 

[FloppySoftware]

Well, then MESCC is really bad in compiling. Compare MAXAM and the new French assembler. For about 150 KB Z80 source MAXAM need about 10 minutes, and the French assembler does it in a small amount of seconds. It's all doable.


BTW: This was one of the main reasons for me to develop FutureOS - to have software which is that efficient, that new hardware is not needed. And I still stick to that. Using a CPC instead of an emulator is my true choice and I wouldn't like to have in any other way. 

MESCC is a compiler, not an assembler. 

Full compilation from a C source file, to an executable COM file for CP/M, involves three steps:

- Compilation with MESCC.
- Assembling with ZSM.
- Loading with HEXCOM.

BTW: My humble PCW has not enough space in its (missing) hard drive to let me compile anything bigger in size than... 48 Kb? 

[TFM]

MESCC is a compiler, not an assembler. 

I know, therefore I wrote 'compiling' and not 'assembling'. 


Also, even if I don't like C, there is a Small C for FutureOS, which does even more than the few steps you indicated. In addition there are optimization steps f.e. However, it's way more quick! 


BTW: HEXCOM.COM does not load, it converts from Intel HEX format to an executable application ending with .COM. 

[FloppySoftware]

I know, therefore I wrote 'compiling' and not 'assembling'. 


Also, even if I don't like C, there is a Small C for FutureOS, which does even more than the few steps you indicated. In addition there are optimization steps f.e. However, it's way more quick! 


BTW: HEXCOM.COM does not load, it converts from Intel HEX format to an executable application ending with .COM. 

Well, I said that because you were comparing a compiler against two assemblers!

Oh yes, I forgot to mention optimization step, in charge of ccopt.

And, well, in the CP/M world the first hex to com converter was... LOAD. Nice name, it'sn it? 

Anyway, I am happy if you are happy with Small-C for FutureOS.

MESCC is Small-C too.

[TFM]

But half an hour? That really needs some optimization for compiling. 

[Puresox]

A few more CPC wins
Chuckie Egg -
Jet Set Willy -
Guardian 2 -
Chase HQ -