Which bit is complaining about it being write-protected exactly? Is it SuperDiskImage? Is it write-protected when you mount TD0:?

If you're referring to my bundled program "SuperDiskImage", then it supports raw image files (which includes .ADF and .D64), as well as Amstrad/Sinclair .DSK files, and Atari .ATR files. It can also write basic .IPF files as long as it doesn't contain any fancy copy-protected blocks.

To write DMS files I'd need the file format it uses, which I don't have....

Edit: To write a DMS file, just use DMS as normal:
DMS WRITE FROM filename.dms TO DF0:
(or whatever the syntax is. If you're using TD0:, use that instead of course)

That's what annoys me, people thinking he's the developer because of that interview.
I don't work for John any more but I'm not aware of anyone else working on it.
I don't believe John had anything to do with the original code though.

What annoys me about "developer interview" is that he's not the developer! The developer is John Jones-Steele (who ported Sim City 2000 and Ultima VI to the Amiga, and Speedball II to the CD32, among many other things).
If you want to ask any pertinent questions to the actual developer let me know and I'll ask him next time I go next door....

FWIW, John would I'm sure have no problems with an Amiga port of Putty Squad, but it won't be up to him, as he's just the coder.

You can see his company Facebook page here:
https://www.facebook.com/pages/Broadsw ... shing-Ltd/150221391661263

@broadblues

Of course - any added complexity will slow things down. On a single core system you don't need to worry about arbitration of cores.

Of course the increase in speed far outweighs the decrease, but nonetheless, technically speaking, SMP slows things down for a single task running on a single core (which is what affects responsiveness).

I think what the original poster was worried about was that all the added bells and whistles would make AmigaOS feel like Windows - it won't. :)

It's true that adding more features "under the hood" (e.g. protected memory, SMP etc) will slow things down, but with the speed of modern CPUs, you won't notice. Don't think that because OSes like Windows, Linux and OS X have memory protection and are often very unresponsive, that those are cause and effect; they're not. If you look at RT kernels and many other microkernels (e.g. QNX) they can be incredibly responsive, while still offering such features.

In other words, don't worry!

Fantastic, thank you! That should help future coders. :)

Thank you! That works!

I wish that was documented somewhere though! I could find nothing about this anywhere!

Hi everybody,

I have a large number of bitmaps (all the same bitmap data) which I want to change the source bitmap of on the fly.
When I change the MUIA_Bitmap_Bitmap at the moment, nothing happens until I iconify and bring back the window - at which point it all looks correct.

How can I force MUI to change the bitmap source data safely and cleanly?

I think I may need to make a subclass but I'm not sure how to do this with a Bitmap class and make it able to use the standard MUI bitmap class but redraw it on demand.

Can anyone help?

Thanks!

This is what puzzles me too. I spent ages faffing around with reversing endianness and eventually via trial and error I found I just needed to shove the bytes up by one. It doesn't make sense, which makes me thing something somewhere is misbehaving (and the fact that Wazp3D renders differently supports this).

I have a new version here by the way:
http://www.retroreview.com/iang/mame_0148u1_ogl.lha

This works (use -video opengl) using the shifted texture.

Thanks for that. I believe I found that it did support BGRA though - it was the UNSIGNED_INT_8_8_8_8_REV that it didn't like.

What I did to make it work was to shift each int32 in the texture up by 8 bits.

Seems to work so far.... although I don't think Wazp3D liked it so I think something's not doing what it should.

It's only a stop-gap until we have proper OpenGL support anyway, though.

@Atheist

I would be very careful about this.

You sound very confident that you can get your money back, but it's never a certainty.

A good rule of thumb: Don't risk the money unless you're willing and able to lose it ALL. There's no sure return on anything, especially if your idea isn't patentable, as if anyone else cottons on to your idea, you can rest assured they'll have much deeper pockets with which to invest, giving them much larger economies of scale, as well as much better marketing budgets.

I would never ever ever borrow money to finance a project which wasn't patentable.

Right, we're getting somewhere now.
With Wazp3d it crashed for some reason, but I didn't look into why. With Warp3D though, using those changes, it worked! All the colours were wrong, of course, but it worked, and gave a hefty speed-up!

Question is what to do about it.
Where can I get the source to minigl latest version? It would be better to add support rather than hacking and slowing down MAME... it may well fix Descent Rebirth too!

I've put a build here:
http://www.retroreview.com/iang/mame_ogl.lha

when you run it, use a script such as:

stack 2048000
set SDLMAME_DESKTOPDIM=320x240
mametiny circus -video opengl -w

Use -video soft if you want to run it with the (working) software renderer.

Sure, I'll get one on-line when I get a moment for you to try!

Thanks!

Yes, the internal format is set to GL_RGBA.

I found that if I set the format to the number of bytes (3 or 4) and set the type to GL_UNSIGNED_BYTE then the glTexImage2D works, and so do the subsequent bindings (though I think the glTexSubImage2D is still failing). However, it does actually render something! Garbage, of course, but something.

Thanks for the feedback.
I think now it's something different. When it calls glTexImage2D it returns an Invalid Operation error. Even when I force the width and height to 256, and tell it to use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV specifically, it still returns this.

I'm suspecting MiniGL or Warp3D or something doesn't quite support what SDL expects....

Hi everybody,

I'm messing around with OpenGL support in SDL for my compile of SDLMAME.

I managed to get it to compile by removing the line
#define GL_ARB_multitexture 1
in GL/gl.h.
Before I removed that I had an error where it didn't know what PFNGLACTIVETEXTUREARBPROC was. By removing the define, the GL/glext.h adds the prototype itself, and defines GL_ARB_multitexture explicitly.

The problem is that MAME just displays white blocks instead of letters, or a big white square for the screen - which sounds like it's unable to render textures.

What's going on here? MiniGL is saying in its header that it supports multitexturing, but it doesn't compile unless I disable the minigl multitexturing bit.

So is multitexturing supported or not? Is this the problem? Is it possible to disable it?

Can anyone help and shed any light on this?

Thanks!

I'm afraid there's absolutely nothing I can do about it, though.
An Atari (i.e. Amiga) joystick is just a dumb device. There's no way of knowing if something is plugged in or not, because a joystick with no directions/buttons pressed just has none of the pins shorted to ground - which of course is what happens when no joystick is attached.

You'll need to hassle Individual Computers to add a sensor to tell whether or not a joystick is attached to cure this...
The program should also allow you to choose which AI driver to use.

Either way, though, it's not the Catweasel and AmigaInput "interfering with each other", more like "working together". :)

Disable the AI Catweasel driver in the AI prefs when you want to use your USB... :)