@vox

Quote:

vox wrote: C65 had some market potential as still there were a lot of C64 fans in East Europe and 3rd world countries that haven`t moved on to Atari.

So a whole new set of HW target at a small target audience with little money and the potential of them outgrowing that system pretty soon.

Exactly the kind of garbage idea that killed C=.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Thread

Quote:

vox wrote: Managment did kill things that had market potential, like c65 ...

You should understand how "C= Worldwide" worked, they developed something at C= USA and when it was ready for production, they asked the subsidiaries in different countries of they want to sell it. That's why strange C= versions like the VC10 / Commodore Max where not sold everywhere.

The C65 development started around 1988-1989, that was the time when ECS was established, the C65 was scraped 1991 just a year before the A1200 was introduced with AGA, a system that couldn't compete with a PC equipped with VGA.


The C65 with its built in floppy was incompatible to the 1541 floppy format and only partially compatible to C64, it would have been in a price range of the A500, that could emulate the C64 with a nearly the same compatibility.

After none of the C= subsidiaries showed interest in the C65, it was cancelled and the prototypes where sold as scrap. Developers that could have sped up the AGA development or could have started with AA+, spend their time developing the C65, an 8-Bit variant no one had asked for, and they knew how fruitless their effort would be.

---

One of the main problems on the Amiga was its heritage as a gaming console, everything had to be PAL/NTSC compatible making it cheap for games but incompatible for serious usage in offices. The Atari ran best when using its own monitors and there was a time when the price of monitor dropped on that of a TV.

AA+ had some good intentions it it, it might have been possible but it only existed on paper and was only an improvement of AGA that already came to late. The 68020 (or 68030) on a AA+ system would have been worth more, than every Audio DSP.

The main problems where:
Improve the Amiga so it could compete with consoles or cheap gaming PCs but keeping the low cost model cheap, so it would attract kids as new customers and game developers.

Improve the desktop model in a ways that makes it usable as an office PC.

LowCost
For a gaming system in the early 90ies it would have needed Doom (GFX: 256 colors, fast chunky GFX, maybe a blitter speeding up this special GFX mode) cheap HD option.

Professional
For an office desktop you would have needed 72Hz 800x600 (or better), HD, Ethernet 68030/25 (or better) Unix optional, 8MB RAM and an AmigaOS supporting RTG.

The professional system must have had some compatibility to the LowCost system (or you would have needed a system in between) ...

And I don't see the need for a DSP there, if you want to speed up floating point operations it would be easier to install a FPU. If you want to have some improvement there, make the development of cards easier, provide custom chips for 3rd party developers with interfaces between ZIII and an Intel compatible chip interface (like VESA) a DSP Card with Midi might have been something for 3rd party developers C= could have supported them with hardware interfaces and some support in AmigaOS.

Last edited by OneTimer1 on 15-Sep-2024 at 02:30 PM.
Last edited by OneTimer1 on 15-Sep-2024 at 11:43 AM.
Last edited by OneTimer1 on 15-Sep-2024 at 11:38 AM.
Last edited by OneTimer1 on 15-Sep-2024 at 11:38 AM.
Last edited by OneTimer1 on 15-Sep-2024 at 11:09 AM.

@OneTimer1

Quote:

OneTimer1 wrote: @Thread And I don't see the need for a DSP there,

Think about it in the same sense as all the media or AI engines in modern CPUs, you don't need them if your running old code or just don't use those features.

But once they are there every app that had a use for it started using them.

So a DSP would be useless on day one, but once there is a big enough install base you would have seen SW that otherwise would have been possible with a much stronger CPU (which might have not been available at that time).

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Kronos wrote: Quote: OneTimer1 wrote: And I don't see the need for a DSP there, Think about it in the same sense as all the media or AI engines in modern CPUs, you don't need them if your running old code or just don't use those features. But once they are there every app that had a use for it started using them.

Well, back in 1990 there wasn't much use of highly specialized hardware, except games they used Copper Blitter and AudioDMA, they made the Amiga performant on games and kept it cheap. PCs where using 3D accelerators some years later outperforming the Amiga with a fast CPU and a fast 3D GFX after 1995.

One of those MP3 to audio chips could have made sense, they where cheap and made a naked A1200HD play MP3, but I don't remember if MP3 was a thing in the early 90ies, Apples iPod was released 2001 and most people didn't use MP3 earlier than this.
There are some examples like the MAS ( https://bigbookofamigahardware.com/bboah/product.aspx?id=1267 )

Last edited by OneTimer1 on 15-Sep-2024 at 04:29 PM.
Last edited by OneTimer1 on 15-Sep-2024 at 04:16 PM.

Kronos Quote:

Think about it in the same sense as all the media or AI engines in modern CPUs, you don't need them if your running old code or just don't use those features.

Amiga codec and datatype libraries could have been replaced by DSP optimized versions granting a performance boost to pre-existing code. High end systems with DSP would install the DSP enhanced versions of libraries while libraries for low end systems would use the general purpose CPU. The 68k Amiga did implement a similar system with the IEEE libraries. High end systems used FPU hardware and low end used soft fp. A large percentage of the performance boost was lost due to conversion from FPU registers to integer registers. This was mostly due to the conversion overhead for most individual fp instructions rather than larger functions. The A1222 without FPU has a similar individual fp instruction conversion overhead but with worse trap overhead and register spill overhead which is significantly worse for a RISC CPU than a CISC CPU. It isn't even a fp accelerator but a decelerator as it is slower than a soft float compile. That was poor planning where good planning can provide a performance boost for old code. Some of the performance gain may be lost by abstraction and interface overhead but it was still the way to go.

Kronos Quote:

But once they are there every app that had a use for it started using them.

If a processor/unit becomes standard then it will be used and removing it can cause major problems, like removing the standard PPC FPU in the A1222.

Kronos Quote:

So a DSP would be useless on day one, but once there is a big enough install base you would have seen SW that otherwise would have been possible with a much stronger CPU (which might have not been available at that time).

It's not so much that the DSP would be useless as I have written above but limited use decreases the value compared to a more general purpose CPU upgrade. Your point is still valid though.

The need for digital signal processing increased over time while the DSP practically disappeared from the desktop/workstation.

1. tiny accumulator arch CPUs with minimal pipelining, few registers and no caches
2. CISC CPUs with minimal pipelining, more registers, more features & maybe some caches
3. DSPs introduced with more pipelining, more ALUs but simplified, specialized, no data cache
4. RISC CPUs with shallow/moderate pipelining, many registers, simplified, maybe caches
5. CISC CPUs increase pipelining & caches closing the gap & surpassing many RISC CPUs and DSPs
6. DSP instructions and extensions are added to CPU ISAs
7. SIMD units replace the DSP for streaming digital signal processing
8. 3D unified shader hardware can be used for highly parallel digital signal processing

With multi-core SMP, each core has a powerful SIMD unit that far surpasses old DSPs and being tightly coupled to the CPU reduces the latency. Unified shaders have higher latency overhead with discreet GPUs but integrated HSA GPUs can have must lower latency increasing the opportunities to make use of the GPU hardware that often uses more than half of the silicon of a SoC.

It is interesting how much hardware is wasted for unnecessary specialized tasks which you touched on. Integer units and FPU units are still basic general purpose units. The SIMD units are not necessary with FPUs and take outsized resources for how often they are used (except x86-64 which replaces FPUs with SIMD units). Security/Crypto units are nice and probably fairly cheap but unnecessary. AI units are definitely unnecessary with hype likely outpacing demand. Even the integer units themselves have grown fat with thousands of instructions even for not so reduced instruction set RISC architectures when the 68000 started with only 56 instructions. Transistors are cheap but the case could be made for simpler, easier to program, more general purpose and somewhat cheaper CPUs.

@Kronos

OK I understand C65 was too little, too late for too high price and agree C128 could be skipped to C65 with C64 mode earlier, bbut did not happen. At C128 days, such Loki level 8 bit computer would be a boom.

@matthey

Nice example if DSP was standardized on Amiga, it could be well used by OS, not just be Jaguar style dongle chip. That would be standard part of A3000 plus, then A1200, A4000 and even CD32, like e.g. CD32 had MPEG hw module as option, but being standard. I believe it can be used for mp3 decoding too.

Last edited by vox on 18-Sep-2024 at 09:36 AM.

_________________
Future Acube and MOS supporter, fi di good, nothing fi di unprofessionals. Learn it harder way!

@vox

@Kronos

Quote:

Kronos wrote: So a DSP would be useless on day one, but once there is a big enough install base you would have seen SW that otherwise would have been possible with a much stronger CPU (which might have not been available at that time).

But DSP fails to keep it cheap. And - as you say - on day one it would be useless. The combination of higher price and slow adoption would be fatal.

Even if the A3000+ (which was anything but cheap) had been released, DSP wouldn't make it into the Amiga world until 1992 at the earliest. By this time PCs were the primary gaming platform and the Amiga wouldn't survive without being easy to port to. Cheap addons that facilitated that would be worthwhile, while exotic hardware that required extra development work with a steep learning curve (DSP) would not.

Furthermore even in 1994 the A500 was still the most owned Amiga model. Many fans were switching to the PC, but their A500s often got passed on to others who hadn't yet experienced the wonderful world of Amiga. That meant developers would continue to target the A500 as well as the A1200, because that's where the market was. Games that needed DSP wouldn't be able to run on both machines, which would severely limit sales until the number of A1200 users reached 'critical mass' (if ever).

DSP was one of the things that caused the Atari Falcon to fail, for similar reasons. The machine was expensive compared to the A1200, and due to the crippling 16 bit bus the CPU couldn't reach its full potential. That meant the DSP chip would have to be pressed into service for stuff it wasn't intended for (eg. texture-mapping) that could take years to perfect. Meanwhile even the STe's enhancements weren't being fully utilized - 3 years after it was released!

DSP was being used in PCs too, but hidden away inside modems and sound cards doing dedicated jobs. So PC developers could stick to writing generic code that worked on a wide variety of machines. The Amiga was already suffering from the trap of custom hardware which had to be programmed directly for best performance. DSP would only make it worse. 30 years later Amiga fans would still be whining about how greedy developers didn't make best use of the Amiga's advanced features, when it was actually Commodore's fault for wasting money on exotic chips instead of putting in the stuff developers really needed (faster CPU, more bandwidth, chunky graphics, synth sound...).

Last edited by bhabbott on 18-Sep-2024 at 10:11 PM.

@vox

> At C128 days, such Loki level 8 bit computer would be a boom.

The C128 had a very compatible C64 mode and it could read/write C64 floppies and datasettes.

I often criticized the C128 for not bringing advantages in the C64 mode but was much more compatible to the C64 than a C65, maybe C= should have skipped the TED computers like the C16/C264 instead.

@OneTimer1

Quote:

OneTimer1 wrote: @vox [quote]I often criticized the C128 for not bringing advantages in the C64 mode but was much more compatible to the C64 than a C65.

One big problem with the C65 was the internal disk drive. Compatibility was much higher when using a 1541 drive, but that didn't come with the machine so...

There were other issues too, but I think the main problem was new 'foreign' graphics modes that weren't easy to adapt to. Developers wouldn't mind tweaking their code a bit to work on the new machine - particularly if they could take advantage of the more powerful hardware. But they wouldn't be keen on completely rewriting code and creating all new graphics, to get a result that was a poor copy of the Amiga. Similarly, potential customers would look at the specs and think "why not just get an A500?".

Quote:

maybe C= should have skipped the TED computers like the C16/C264 instead.

Definitely. The TED series was a disaster. That was the primary reason the C128 got C64 compatibility (the original design didn't) - Bil Herd insisted that they not make the same mistake again!

@cdimauro

Quote:

WHEN? WHO used them?

When? Since 1988 onwards, but especially since 1995.
Who? Anyone with capable hardware. Some would argue that a programmable DSP is slightly more practical than a strict usecase chip like the CL450 used in the FMV and on PeggyPlus.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

The main problem with the 6502 was they always targeted a 40 pin chip socket...so future variants could be drop-in upgrades.

It was highly customizable due to it's simplicity.

The 65816 used double duty on the data pins to achieve 24bit address space...to maintain pin-compatibility.

The 8/16bit 65CE02 in the c65 added extra registers including a dedicated 16 bit stack pointer which gave you up to a full 64k of stack space for the whiners complaining about a 1 page stack. It also codified the relocatable Zero Page into a new B register instead of relying on an MMU like the 8502 did.

Variants made for Renesas (and others) added MUL and DIV for you math whiners...despite the fact that it had 2 math modes, decimal and binary and math was fast using zero-page but whiners will whine about 16 bit math...

The relocatable zero page is a big increase in performance. 3 cylces instead of 5...
Zero page addressing essential gave the 65xx line 256 registers ... by design...per Bill Mensch himself.

Whiners complain about a wasted cycle when crossing page boundaries on branches and JSR ... that was also fixed in the 65CE02. In fact, JSR could use a 16 bit address in the 65CE02.

The 65C02 and 65816 were 20% more efficient than the original 6502. Many instructions executed in 1 cycle.
The 65CE02 improved over the 65C02 by 25% as virtually all instructions executed in 1 cycle...so roughly 50% over the original 6502 clock for clock.

The 65816 and 65CE02 we great 16 chips. Once it came time for 32bit, Mensch recommended ARM...despite having a 32 bit design.

Now we have an ARM-based A600GS...finally.

@OneTimer1

Quote:

OneTimer1 wrote: @vox > At C128 days, such Loki level 8 bit computer would be a boom. The C128 had a very compatible C64 mode and it could read/write C64 floppies and datasettes. I often criticized the C128 for not bringing advantages in the C64 mode but was much more compatible to the C64 than a C65, maybe C= should have skipped the TED computers like the C16/C264 instead.

The VIC-IIe introduced (officially) interlace support and a 2nd color memory bank.

The C128's MMU allowed for relocatable Zero Page and Stack Pointers. This means code could have been rewritten for C128 mode for the same application could benefit from accessing memory repetitively 40% faster within a page of memory.

The extra 64k could have been used to unwind loops...as has been done in more recent demos and games.

As you have seen, many C64 games would detect C128 hardware and run 30% faster by cycling 2Mhz mode on and off in the vertical border. This is also what introduced incompatibility when old software would accidentally trigger 2Mhz mode.

So the problem wasn't the C128 but was actually the C64 became a lowest common denominator that developers would target. Just as a 512K A1000/500 became the main Amiga target.

Ultima V was a C128 native game that added music over the C64 version...however it could have easily been made as an 80 column game. As you can see, a hobby developer has somewhat attempted to make it a VDC 80 column game (in BASIC! ...Basic 8 technically but that was just to add native VDC calls to BASIC 7) with almost EGA quality graphics:

https://www.youtube.com/@the8bittheory/videos

Here is a C64 Doom-ish demo that when ported to the C128 gained 160% framerate improvement using the methods I described above.
(like it totally needed them MUL and DIV instructions dude!! )
https://www.youtube.com/watch?v=1tDflgqJlTw

Last edited by Lou on 19-Sep-2024 at 07:52 PM.
Last edited by Lou on 19-Sep-2024 at 07:48 PM.
Last edited by Lou on 19-Sep-2024 at 07:37 PM.
Last edited by Lou on 19-Sep-2024 at 07:34 PM.
Last edited by Lou on 19-Sep-2024 at 07:31 PM.

kolla Quote:

When? Since 1988 onwards, but especially since 1995. Who? Anyone with capable hardware. Some would argue that a programmable DSP is slightly more practical than a strict usecase chip like the CL450 used in the FMV and on PeggyPlus.

Yes. A DSP that can be used for multiple purposes is better than the CL450 or other dedicated hardware that could practically only be used for a single purpose, provided they are the same cost. A DSP potentially could have been used for the FMV decoding and for other purposes which would have made the CD32 more powerful. CBM still should have had a 68EC030+AA+@28MHz instead. It may have been possible to license the AT&T DSP and include it in the Amiga chipset potentially lower the cost too. There wasn't much room for dedicated hardware back then though. There is more and more dedicated hardware in more modern computers but cost is still very important.

Eben Upton of RPi fame talks about his relationship with Sony who owns a minority stake in RPi like ARM. He talks about Sony's AI capabilities but says the following.

https://youtu.be/-_aL9V0JsQQ?t=1531 Quote:

And I mean Sony has been a great partner. And then they've got some really nice capabilities in AI. We've never integrated AI into the core product, AI acceleration into core products. I don't think we ever will. And the reason we won't is because it will only ever be of interest to a minority, potentially a sizable minority, but a minority of our customers. It's quite an expensive feature to put on the board. And if you think you're taxing every customer to pay for a thing, which is only of interest to 10% of the people.

RPi is the new and better low cost producer replacing CBM, The video goes on to talk about their mentality on other low cost items like a $0.20 USD ADC which is still missing while wireless networking is the only new "capability" added to newer generation RPis. The video also gives number of RPi units sold which peaked at 7 million a year with a 4.5 million unit backlog in 2021. It's a great video that makes me wonder why the Amiga is perpetually cursed by inept leadership and ignorant Amiga IP squatters who won't give up even with hundreds of computer units not even selling in the case of A-Eon and out of money in the case of Hyperion. They should get out of the way if they care at all about the Amiga.

@vox

Quote:

vox wrote: Nice example if DSP was standardized on Amiga, it could be well used by OS, not just be Jaguar style dongle chip. That would be standard part of A3000 plus, then A1200, A4000 and even CD32, like e.g. CD32 had MPEG hw module as option, but being standard. I believe it can be used for mp3 decoding too.

Again with the DSP?!?

@OneTimer1

Quote:

OneTimer1 wrote: @vox > At C128 days, such Loki level 8 bit computer would be a boom. The C128 had a very compatible C64 mode and it could read/write C64 floppies and datasettes. I often criticized the C128 for not bringing advantages in the C64 mode but was much more compatible to the C64 than a C65,

Exactly. The main problem here is their CPU: the C128's one is almost the same as the one from the C64, so it give an almost perfect compatibility with the C64 software.

The C65 one is quite different, and hurting a lot the compatibility (just think about turbo tapes and turbo disks software).

As usual, Commodore managers and engineers had no idea of what was really needed...
Quote:

maybe C= should have skipped the TED computers like the C16/C264 instead.

Indeed!

@kolla

Quote:

kolla wrote: @cdimauro Quote: WHEN? WHO used them? When? Since 1988 onwards, but especially since 1995. Who? Anyone with capable hardware.

And here are the keywords.

Now think about Commodore's primarily market, and you've answered yourself...
Quote:

Some would argue that a programmable DSP is slightly more practical than a strict usecase chip like the CL450 used in the FMV and on PeggyPlus.

Sure. And how many of Commodore customers would have gained something from it?

That's the point. As it should always be: think about the market of reference.

@Lou

Quote:

Lou wrote: The main problem with the 6502 was they always targeted a 40 pin chip socket...so future variants could be drop-in upgrades. It was highly customizable due to it's simplicity. The 65816 used double duty on the data pins to achieve 24bit address space...to maintain pin-compatibility. The 8/16bit 65CE02 in the c65 added extra registers including a dedicated 16 bit stack pointer which gave you up to a full 64k of stack space for the whiners complaining about a 1 page stack.

Finally: it was a mess to deal with the stack page, which made the stack programming a nightmare, not even talking about the HUGE drop in performance.
Quote:

It also codified the relocatable Zero Page into a new B register instead of relying on an MMU like the 8502 did.

It's a modest speedup, for what it's needed. But, better than not having it.
Quote:

Variants made for Renesas (and others) added MUL and DIV for you math whiners...

Guess what: MAYBE because they... rolling drum... NEEDED?
Quote:

despite the fact that it had 2 math modes, decimal and binary

Oh, the decimal mode: sooooo much useful, eh?
Quote:

and math was fast using zero-page

It's not only math which gained the ONE cycle advantage, but all code which was able to use it instead of the absolute addressing mode.

Anyway, it's only one cycle: helps a bit, but doesn't solve the intrinsic performance problems of the processor on dealing with more completed (and modern) code.
Quote:

but whiners will whine about 16 bit math...

It's not only about math: arrays handling is one of the above more complicated things which shows how poor is a 65xx processor.

YOU have pulled out a challenge and proposes to increase the elements of an array. I've provided you the equivalent C code (just two lines of effective code), waiting a 65xx implementation from you (I'll give the 68000 one), and guess what: you disappeared.
Quote:

The relocatable zero page is a big increase in performance. 3 cylces instead of 5...

False: it's just ONE cycle. You never opened a 65xx programmer's manual in your life...
Quote:

Zero page addressing essential gave the 65xx line 256 registers ... by design...per Bill Mensch himself.

LOL. Absolutely no! It's a commodity are where to park some values, but definitely NOT like a register.

In fact you CANNOT do the SAME things that you do with any of the registers.

As usual, you don't know of what you talk about!
Quote:

Whiners complain about a wasted cycle when crossing page boundaries on branches and JSR ... that was also fixed in the 65CE02. In fact, JSR could use a 16 bit address in the 65CE02.

Who's whining? ALL processors got improvements, as it was natural with their successors.
Quote:

The 65C02 and 65816 were 20% more efficient than the original 6502.

Source?
Quote:

Many instructions executed in 1 cycle.

No. Many 1 byte instructions executed in 1 cycle. Which isn't "many".
Quote:

The 65CE02 improved over the 65C02 by 25% as virtually all instructions executed in 1 cycle...so roughly 50% over the original 6502 clock for clock.

ROFL.

Again, you don't know of what you're talking about!

ONLY the ONE BYTE instructions executed in one cycle, but MOST of the instructions are LONGER and require MORE cycles for their execution!
Quote:

The 65816 and 65CE02 we great 16 chips.

It's unbelievable of how many load of b@lls you're writing in a single comment.

Again, no! The 65EC02 is NOT a 16 bit chip!
Quote:

Once it came time for 32bit, Mensch recommended ARM...despite having a 32 bit design.

Guess what: it was NOT convenient, because the 65xx is crap for modern computing.
Quote:

Now we have an ARM-based A600GS...finally.

It could have used everything: it's just an emulator and not a real 68k machine.
Quote:

Lou wrote: @OneTimer1 Quote: OneTimer1 wrote: @vox > At C128 days, such Loki level 8 bit computer would be a boom. The C128 had a very compatible C64 mode and it could read/write C64 floppies and datasettes. I often criticized the C128 for not bringing advantages in the C64 mode but was much more compatible to the C64 than a C65, maybe C= should have skipped the TED computers like the C16/C264 instead. The VIC-IIe introduced (officially) interlace support

"Great" addition...
Quote:

and a 2nd color memory bank.

Is done by the VIC-IIe or by the MMU?
Quote:

The C128's MMU allowed for relocatable Zero Page and Stack Pointers. This means code could have been rewritten for C128 mode for the same application could benefit from accessing memory repetitively 40% faster within a page of memory.

LOL, other balls.

How? Where this 40% comes from? Any data? Any example?
Quote:

The extra 64k could have been used to unwind loops...

Wasting even more memory. Nice...
Quote:

as has been done in more recent demos and games.

I hope here that you're talking of something using the VIC and not the VDC.
Quote:

As you have seen, many C64 games would detect C128 hardware and run 30% faster by cycling 2Mhz mode on and off in the vertical border. This is also what introduced incompatibility when old software would accidentally trigger 2Mhz mode. So the problem wasn't the C128 but was actually the C64 became a lowest common denominator that developers would target. Just as a 512K A1000/500 became the main Amiga target.

Unfortunately, that's exactly the case. Only the 1200 introduced a new development platform, but it took 7 years from the original machine to have it.
Quote:

Ultima V was a C128 native game that added music over the C64 version...however it could have easily been made as an 80 column game. As you can see, a hobby developer has somewhat attempted to make it a VDC 80 column game (in BASIC! ...Basic 8 technically but that was just to add native VDC calls to BASIC 7) with almost EGA quality graphics: https://www.youtube.com/@the8bittheory/videos

ROFL. You don't even understand the differences which are clearly shown in the videos.

No, the graphics is NOT "almost" the same of the EGA. There are a lot of details which are missing, as it was clearly shown when the guy compared the two versions.

Only a blind can't see it... or fanatical, which is the same in this case.
Quote:

Here is a C64 Doom-ish demo that when ported to the C128 gained 160% framerate improvement using the methods I described above. (like it totally needed them MUL and DIV instructions dude!! ) https://www.youtube.com/watch?v=1tDflgqJlTw

Using... an ARM for the execution: "great" work for the 65xx.

P.S. No time to read it again, but I don't care.

@cdimauro

Boy someone is still but-hurt because their fighting-game got criticized for 2 frames of animation per move compared to actual professional games huh?

I've noticed you are quite combative with many users on this forum.
You also deny the words of a source who've built their own entire computer (and many other sources) because it hurts your feelings. Poor baby.

You also continue to troll by proving you don't even follow links.

Perhaps you need a new hobby, eh?

Last edited by Lou on 20-Sep-2024 at 08:56 PM.
Last edited by Lou on 20-Sep-2024 at 08:54 PM.
Last edited by Lou on 20-Sep-2024 at 08:53 PM.
Last edited by Lou on 20-Sep-2024 at 08:52 PM.

@Lou

Quote:

Lou wrote: @cdimauro Boy someone is still but-hurt because their fighting-game got criticized for 2 frames of animation per move compared to actual professional games huh?

That happens in your imaginary world. The reality is that you're writing a big list of balls (included the "2 frames" in my games), which I took apart piece by piece, and which you were unable to replicate. That is why you suffer and to appease your violated ego you invent things that are only in your head, so that you can console yourself.
Quote:

I've noticed you are quite combative with many users on this forum.

Only with the jokes of (step)mother nature.
Quote:

You also deny the words of a source who've built their own entire computer (and many other sources) because it hurts your feelings. Poor baby.

?!? Another pearl of your violated ego?
Quote:

You also continue to troll by proving you don't even follow links.

Again, in your imaginary world: I've seen your videos, and many others from your source, and my above reply is exactly because of that.

May I suggest you to use a good pair of glasses, since you're not able to spot the gross and very obvious differences?
Quote:

Perhaps you need a new hobby, eh?

The cat was looking for something new when the mouse it was playing with died...