Curse of the SDL

[matthey]

if this is legal, then its maybe possible to get SDL 2D working with warp3d and also direct access to bitmap can work.when a program want get a SDL lock to access the surface direct, warp3d need tell that it should draw all currently added quads.and if a user not call SDL lock, then all is draw in SDL_redraw commands.

I think that's close to working but...

1) Would SDL try to access the SDL surface memory outside of this bitmap? Warp3D would provide clipping of the SDL surface that is off the bitmap but once clipped, there isn't any bitmap memory outside of the clipped bitmap.

2) The SDL surface "changes" would not be alpha blended. Accesses to the SDL surface (now bitmap) would only work where the surface replaced (pasted over) what was in the bitmap.

[unusedunused]

I think that's close to working but...

1) Would SDL try to access the SDL surface memory outside of this bitmap? Warp3D would provide clipping of the SDL surface that is off the bitmap but once clipped, there isn't any bitmap memory outside of the clipped bitmap.

2) The SDL surface "changes" would not be alpha blended. Accesses to the SDL surface (now bitmap) would only work where the surface replaced (pasted over) what was in the bitmap.

when a SDL program call a lock, the cgx function for a lock is called.cgx can not do alpha blendet too.no system do alphablend when write data to a bitmap direct with sdl.

Code: [Select]

int CGX_LockHWSurface(_THIS, SDL_Surface *surface)
{

if (surface->hwdata)
{
// D(bug("Locking a bitmap...\n"));
if(!surface->hwdata->lock)
{
Uint32 pitch;
           if (surface->hwdata->bmap)
  {
if(!(surface->hwdata->lock=LockBitMapTags(surface->hwdata->bmap,
LBMI_BASEADDRESS,(ULONG)&surface->pixels,
LBMI_BYTESPERROW,(ULONG)&pitch,TAG_DONE)))
return -1;
  }

.......


[chris]

There are some pointless projects (about www), I don't want to say what and others doesn't know what kind of web broweser Netsurf is, so they think that A-Web is more usefull.

Here http://eab.abime.net/showthread.php?t=43738 somebody said that that "I maybe would consider doing an OS3 ReAction-based port, I'd have to be convinced that it was much better than AWeb though, which I'm not. There's no menus on this version (!) so I'm not sure what features it offers, if any."

I don't have enough knowledge and english is not my motherlanguage, so I woun't bother to arguing him.

So Bern do you know where is Netsurf feature list?

It is surely on the NetSurf website.

Firstly, the SDL version is the "framebuffer" frontend.  It has been repeatedly said by the core developers that this frontend is for debugging and example purposes only and is not intended to be a feature-complete frontend.

Off the top of my head, briefly, the OS4 version has the following features:
* CSS support (of course!)
* Full UTF-8 character support
* ReAction-based GUI
* Tabbed and multi-window browsing
* Cookie browser
* Local (thumbnail tree-based) and global history windows
* Hotlist window, hotlist menu
* ARexx port
* Full drag'n'drop throughout (loading, saving, uploading, drag text selections to text input boxes, history entries to browser windows, etc)
* Load images through DataTypes (also partial support for embedded audio)
* Native clipboard support for text and images, can also save objects as IFF
* PDF output and printing (currently disabled - will return when core fixed, have requested that to be on the list for this year)
* HW accelerated blits and resizes for images using OS4.1's compositing functions

There are a load of core and other features I've missed, but other than the first two, I don't think any of that is in the current 68k SDL version.

1. Get smaler memory footprint, 8bit screens would help?
2. Disable requirement of true type fonts so that it would work with AGA
3. Give it a native GUI

1. Would be useful for OS4 too.  A modification to my new DataTypes loader to not use V43 mode, and only using that for images rather than the core/internal image loaders, might make this easier, albeit probably not quicker (text and line drawing will still need changing of course)
2. TrueType fonts do work with AGA, the problem is converting outline fonts to bitmaps is very slow (also the case for Commodore's Intellifont code).  Using bitmap fonts isn't a major problem though, my very first release would load any fonts and convert the text to the local character set and print it with Text().  The only reason I open outline fonts directly is because that is the only way to print UTF-8 characters, but it is slower.  This might be an acceptable trade-off for 68k, although I'd suggest making it a configurable option.
3. No comment!

[chris]

But netsurf team change the backend interface lots, so itix version do not work with newer netsurf core.

itix does not want change code to new backend interface and give up netsurf for MOS.
I can understand him, its really not nice what netsurf developers do, they often change their API

What do you expect them to do?  Keep it exactly the same so no improvements can be made?

So netsurf 68k use SDL, because SDL is mainted by a netsurf developer and all backend API changes he add in the SDL code.

All the officially supported frontends get updated when the core API changes.  I usually do it myself for the OS4 version anyway, but if not the person who makes the core changes will update it (eventually).  They can't necessarily test them all, but the basic changes are done so any errors are trivial to fix.

The MUI version was never an officially supported frontend so hasn't had this treatment.  Moreover, it wasn't even in SVN until after a major core change had already rendered it uncompilable.  I suspect it is so far behind now that it would be easier to start again.

[Karlos]

Poking the native texture surface in warp 3d is a bad idea. It's abstracted away for a good reason. The permedia alone will do your head in, you have subpatched addressing that makes any simple linear sequence of texels considerably more awkward to access.

[matthey]

Poking the native texture surface in warp 3d is a bad idea. It's abstracted away for a good reason. The permedia alone will do your head in, you have subpatched addressing that makes any simple linear sequence of texels considerably more awkward to access.

I know it's a bad idea. I was just pointing out that it's easy to figure out where the textures "probably" are on the card. If the Permedia can't access the texture in VMEM as a linear "bit map" then it's highly probable that SDL doesn't do that either. It probably allows access to a copy of the texture in main memory and copies it to VMEM through the gfx bus much as would be needed with Warp3D. It's just that it's slower on classic Amiga's with a slow gfx bus . I think it would still be faster than copying the whole visible bitmap from main memory to VMEM every frame in cases where the textures/bitmaps are small, seldom poked, and don't need to be converted).

Are you the author of the 68k Warp3D Permedia drivers? If you are, there is a floating point rounding bug with at least one variable of Warp3D which kas1e (author of the Vague magazine) pointed out to me. Any chance of getting a fix for that or are you prohibited again? I guess wrong colors with the Permedia driver isn't as bad as trampling innocent memory trying to write the Zbuffer with the Avenger driver.

[Karlos]

I know it's a bad idea. I was just pointing out that it's easy to figure out where the textures "probably" are on the card. If the Permedia can't access the texture in VMEM as a linear "bit map" then it's highly probable that SDL doesn't do that either.

Sorry, I don't think I was entirely clear. The Permedia2 supports 3 addressing modes that are used for internal VRAM buffers.

1) Linear - bog standard, hardware-aligned buffers that are linear spans of pixels. All AmigaOS/RTG BitMaps, whether visible or off-screen use this format.

2) Patched - reorganised buffer that effectively dices a larger buffer into small squares that are then stored sequentially. These cannot be displayed and are intended for things like the LocalBuffer (Z and stencil). Warp3D doesn't use this format yet, but I have been experimenting with it for the Z-buffer.

3) Subpatched - this is an even more transformed version in which a set of the low order bits of the x and y coordinates into the buffer are interleaved, resulting in an order that generally keeps spatially-neighbouring pixels nearby in memory (often adjacent). This format is typically used for texture data, as it helps increase the performance of filtering (since you always need to sample your nearest neighbours). In Warp3D, textures may or may not be in subpatched format, depending on their size. For textures below a certain width, it is often not faster. IIRC, this format may not be used on the 68K because doing the transform is so slow that not even the bus speed hides it.

(3) is also the reason why the update texture sub image operation in Warp3D is so slow, since performing the operation on only rectangular subset of texels is such a PITA that it's simpler to redo the whole image. I do have problems with that and am aiming to fix it at some stage.

Are you the author of the 68k Warp3D Permedia drivers? If you are, there is a floating point rounding bug with at least one variable of Warp3D which kas1e (author of the Vague magazine) pointed out to me. Any chance of getting a fix for that or are you prohibited again? I guess wrong colors with the Permedia driver isn't as bad as trampling innocent memory trying to write the Zbuffer with the Avenger driver.

Yes and no. I did not write the stock Warp3D 4.2 driver, but I am the author of a range of unreleased revisions that ultimately served as the basis for the OS4.1 driver I'm now doing*. I'll see what the crack is with releasing those as personally, I can't see any reason not to.

*when I have free time, which has not been a lot lately

[itix]

I suspect it is so far behind now that it would be easier to start again.

Indeed. Two years ago (!) I started work to merge MorphOS changes to SVN but it was already too late... so much had changed already.

Luckily porting it over is not that much work... old UI can be reused and many deps have been ported already. And when I ported it years ago I reused some of your code and I guess I could do that again =P

@bernd_afa

Btw ports are never done. They need continuous maintenance or they fall behind quickly were they official ports or not. One example is Freeciv port years ago when it had decent MUI GUI. It was never finished and since Freeciv 2.x it has been obsolete.

[unusedunused]

Indeed. Two years ago (!) I started work to merge MorphOS changes to SVN but it was already too late... so much had changed already.

Luckily porting it over is not that much work... old UI can be reused and many deps have been ported already. And when I ported it years ago I reused some of your code and I guess I could do that again =P

@bernd_afa

Btw ports are never done. They need continuous maintenance or they fall behind quickly were they official ports or not. One example is Freeciv port years ago when it had decent MUI GUI. It was never finished and since Freeciv 2.x it has been obsolete.

I dont know many programs, maybe i think too much in theory but its too hard for the coding style netsurf is do, and it can not work in praxis when every system have a native GUI, so that the backend can be as much unchanged as blender or firefox or other programs with a fixed GUI have.

it was really not good that netsurf API interface was change so many years after netsurf so much.

when they change their lots backend API functions earlier before MUI Version come, i think now we have a MUI version.

so we can say bad luck ;-)

maybe if netsurf get java script and libdoom, there come other changes.So i prefer to wait, because when netsurf support all browser features, risk that backend API need change alot, is not high so high i think

[itix]

@bernd

In my opinion biggest drawback in Netsurf is it is designed for non-multitasking RISC OS. It is single threaded application blocking UI when it is waiting for network or disk activity.

Please also keep in mind API must change in this kind of application. It is unavoidable in cross platform development and C language perhaps is not the best possible choice there...

[chris]

In my opinion biggest drawback in Netsurf is it is designed for non-multitasking RISC OS. It is single threaded application blocking UI when it is waiting for network or disk activity.

I don't think that is a major problem.  NetSurf always stays responsive to input here, only occasionally stalling when converting huge images (which is a rare occurance anyway).  I can load multiple tabs in the background, scroll up and down, switch between them with hardly any pauses.  Of course, on 68k these pauses will be maginified, but the browser has been designed from the start to run as a single task, so it is broken down into small chunks that return quickly before checking for events and doing the next bit.  It effectively does its own internal multitasking.

btw RISC OS is a a multitasking OS, it just happens to be co-operative instead of pre-emptive.

[itix]

btw RISC OS is a a multitasking OS, it just happens to be co-operative instead of pre-emptive.

Ah, right. My mistake. But anyway it leads to single threaded application design. If something blocks UI it also blocks downloading task in background. And vice versa.

[NovaCoder]

I've just done the first non-SDL version of ScummVM RTG and it seems to be a little quicker than the old SDL one, it's now fast enough to play Curse of Monkey Island on 68k

[utri007]

Thanks

[fishy_fiz]

Sorry for the off topic-ness, but:

Curse Of Monkey Island,... awesome game    I didnt really like it much at 1st seeing as I was stuck at the start and it at 1st appears different to the 1st 2, but once I worked out how to get off the boat it quickly became (and still is) one of my fav. ever games. The fact that Id not played it (along with many scummvm games) before helped it feel like a "new" amiga game to me too (played it on my a1200)   Wish I could go back in time a few years to a time Id not played it and experience it all again

I even own 2 (original) copies, just incase something bad should hapen to one of them

@Novacoder

Any particular reason youve only supported certain games in your ScummVM builds? I recently got a copy of Broken Sword that Id love to play on my Amithlon box If it's not too much of a chore is there any chance you could do a full build please ?

[Crumb]

@NovaCoder

Good job! :-)