[meynaf]

Originally Posted by Thorham

Hmm, the only problem I have with WinUAE is the graphics speed, witch is caused by my 'slow' peecee.

Don't you find it much less reactive than your miggy ?

Originally Posted by Thorham

That sucks then. Any way to fix it?

Not for now, and it's not urgent anyway.

Originally Posted by Thorham

Odd Do you know what causes it?

060 was said to pre-decrement destination before reading/writing source, and my test just showed the opposite. Strange, but I can't tell more.

Originally Posted by Thorham

But that's not always handy. Not all errors are fatal. Suppose you supply your utility with a list of files to rename. If some of the files don't exist or are moved/deleted before renaming, then the files witch can be renamed will not be renamed. If the error handling is done by hand, the program can simply skip the files witch are not found, and just rename the rest, and tell the user witch files were not renamed.

Another example would be reserving a chipmem buffer and then killing the system. If there isn't enough memory, then handling the error by hand lets you reserve fastmem, kill the system, and copy some chipmem to fastmem. Only if the fastmem reservation fails, it's a fatal error, and the program can exit.

It's true that it sucks to handle the errors by hand, but it creates a greater level of flexibility.

I agree it's not always handy, but it covers more than 90% of cases (in my actual programs).
However, my system allows to catch errors such as failure in renaming or memory allocation. See it as the try...catch of high-level languages.
So I can still handle errors by hand when needed

Originally Posted by Thorham

It's always the same with those formats, isn't it? How difficult is it to properly document a format? Bah

Yes, and for MP3, documenting the binary format isn't even enough...

Originally Posted by Thorham

Right. I guess I'll have to do some more reading up on my 68020+ knowledge

Maybe ;-)

Originally Posted by Thorham

I can't give you a concrete example, but lets just say that the first version of my kernel became quite messy because of register passing. In such programs it's better to pass the parameters through memory, I think

Did your kernel actually work ? Or was it yet another unfinished project ?

Originally Posted by Thorham

The good old sliced ham, cool Also, scaling can be done during loading for large images, allowing images of nearly any size. I have 2+gig of 24bit bmp Boris Vallejo images, and some are 10+mb (no kidding).

Scaling during loading ? You'll have to scale to fastmem, because you can't kill the system before you're finished loading.

Originally Posted by Thorham

Yes, I do. Hippo Player can eat up a few hundred kb while playing wavs, and with multiple screens open, the chipmem goes down fast. Copying chip to fast is the only solution for this problem.

You use Hippo Player ??? Doh... Play16 is probably better for playing waves, and for the rest, why not DT ?

Originally Posted by Thorham

No, I havent. I'm just a player here

I find dungeon designing more funny than actually playing it. And that code is the main reason I didn't use DM2.

Originally Posted by Thorham

As far as I know all you have to do is add two lines (patchcontrol and then mcp) to your startup-squence. If I were you, I'd download it from aminet again, and try to get it to work. The program really is worth using. If you're using other patches, try removing them

I don't feel the need of changing my patches. What's so great about it ?

Originally Posted by Thorham

That's the only right way, as far as I know. Shouldn't cause any troubles... in theory....

Peter Kunath was forced to do this too for DeliTracker, because of bugs in audio.device.

Originally Posted by Thorham

Yeah, that's true. It's what make peecees suck so much. Love using them, though

But if given same tech level as peecees, Amigas would be much more powerful.

Originally Posted by Thorham

I don't agree. This is the very basis of oo. Assembler just doesn't provide any oo directives. Also, consider that oo should be viewed as an extension of structured programming, and not as a different paradigm. Think about it.

This is ONE of the bases of oo, but oo is more than that.
It's supposed to be a different paradigm.

Originally Posted by Thorham

I mean ridiculous as in words such as sick/wicked/bad meaning cool, etc

Ok then.

Originally Posted by Thorham

Just some settings witch have to be taken care of. Hope it's going to get done.

Some settings witch, yeah, old wicked witch

Originally Posted by Thorham

Indeed. Would be cool to have an emulation of that stuff on the Amiga.

An emulation ? It requires hardware to actually run, AFAIK even on PC.
But it certainly would be cool to have that hardware on the Amiga.

Originally Posted by Thorham

A compiler can't be compared to the brains software. Yes, software, the brain is soft, right

You can consider the brain is both hardware and software if you like. But I don't think it can be software as you know it.

Originally Posted by Thorham

Just because evolution came up with a way that requires such brute force, doesn't mean it can't be expressed algorithmically. Furthermore, how many neurons does the brain need to calculate something like 1234+5678?

Nonsense. The brain will always interpret, where the computer will execute. They can't be compared.

How many neurons a computation requires is irrelevant, as it can be very different from people to people.