Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: utri007 on August 03, 2011, 11:09:27 AM
-
Hi
68k software developement is totally halted, or all new software for 68k amigas is useless SDL ports.
I don't know single usefull SDL port to 68k amigas, dozenz of useless crap.
Seems that nobody isn't trying to do native ports anymore.
Sad part of this is that many of use "real amiga" users has quite much cpu power compared to what it used to be ten years ago.
Some how developers just made tens of 3d and few RTS games with support for 040/060.
There is really few games/apps that really take advantage for 040/060, but plenty of games and apps for 000/020 and all new sofware developent is only for UEA users (SDL).
So what kind of apps and games could theoritically run 040/060? Quite much any PC game that that has requiremt something like 486
-
Your quite right, I'm afraid most of our native coders have moved on or don't have the time any more :(
And in reality the 040 is more like a 486, and the 060 is like a low end pentium.
-
Your quite right, I'm afraid most of our native coders have moved on or don't have the time any more :(
And in reality the 040 is more like a 486, and the 060 is like a low end pentium.
Both of which are outperformed by most Mobile Phones you get now... The last mobile phone I had that didn't even have a 3D graphics chip was nearly 5 years ago!
-
On the bright side, there's a whole bunch of apps and games for the Amiga that you have never tried.
-
I just wish that somebody could do native Netsurf port to 68k amigas, after that I could use my amiga quite much more.
Nice thing would be nice car game, like carmageddon 1 and settlers type city buildin game, maybe some sport game??
Yes I know that any mobile phone is more powerfull than my current amiga, but Amiga is hobby and there is lot of unused resources.
http://michael.santovec.us/games/carma2.jpg
There is also freesyndicate, wich should run 040/060, SDL port of it would be useless... but native should run just fine. That for higer resolutions, more colors etc. Freecraft would be nice also... what else? Quite many possible ports...
-
@utri007
It's not just a problem of having a decent SDL library port, SDL games seem to be pretty unoptimized too.
A proper Scumm port without using SDL nor ixemul would be a nice thing to have. Perhaps graphics could be converted on first run to planar and stored in a "cache" directory to avoid using chunky graphics too. And using paula sound instead of AHI would be also a nice addition.
And rewritting some parts may be required to get decent performance too: at first look Scumm seems to lack functions to load a big bitmap in gfxram and scrolling the viewport simply exchanging a pointer (something like ScrollVPort() ). Instead it uses the usual peecee bruteforce approach copying the entire screen to the gfx buffer each frame.
Scumm also seems unable to keep gfx in gfx ram and draw them on screen using some kind of blitter. For modern games the dirtybox approach it uses it's probably better (for fast cpus without gfx acceleration) but for old games like Monkey Island 1 or 2 you don't move hundreds of objects simultaneusly and using our dear blitter to draw the graphics seems more interesting, specially taking in account that you won't be throwing 50 different frames per second but you could keep in chipram most used images cached.
PS: please note I have not studied much Scumm sources but these are my first impressions when looking at the sources. You could claim Scumm is multiplatform but if it had been designed from scratch thinking in something else than a 64KB VGA framebuffer it would have been way faster with decent hardware (like our miggies). It's funny that you need a fast cpu to play games like Monkey Island that looked, sounded and played perfectly on unaccelerated classics
-
you know you can write your own backends for scummvm that dont require sdl... there is even wiki pages for devs for scummvm here (http://wiki.scummvm.org/index.php/HOWTO-Backends). I was a scummvm dev for a while, and making scummvm so portable requires different kinds of tradeoffs.
-
I just wish that somebody could do native Netsurf port to 68k amigas, after that I could use my amiga quite much more.
Well, why don't you do it? I do not mean to sound harsh or offend you but instead of complaining about it, why don't you try to do it yourself?
There are a plethora of free Amiga books you can download to teach yourself programming, you have a pool of people to post questions to on the Amiga forums, I'm sure the Netsurf forums would think this is neat and help you when you get stuck, and since Netsurf is OS you can view the working code as your port! Frankly, you have it better than people starting out 25 years ago!
I'm not saying it will be easy but you will learn a lot, you will increase the 68k programming pool, and as you learn you can port/create other projects.
In the end, I get frustrated with people who whine about programming while not even trying to help. If you want a port or a feature or an upgrade start working on it! You'll get much better help if you are trying than complaining.
As a CS Professor I have a favorite quote from the Simpsons: "I've tried nothing and I'm all out of ideas!"
In the end, I hope I have not offended you but motivated you! Get out those books and start writing! You have a HUGE amount of resources at your disposal! Netsurf code is open source so you have a blueprint to work from.
Cheers!
-P
-
you know you can write your own backends for scummvm that dont require sdl... there is even wiki pages for devs for scummvm here (http://wiki.scummvm.org/index.php/HOWTO-Backends). I was a scummvm dev for a while, and making scummvm so portable requires different kinds of tradeoffs.
First of all thank you for contributing to Scumm, it's a nice piece of software. Nice to see there's somebody from Scumm team here :-)
But I have to add that IMHO some functions for scroll could have been written so platforms without hardware scrolling capabilities could have used a software backend and platforms with hardware scrolling could have used hardware scroll. With the current implementation it's always software mode.
I think the same about blitting objects located in gfx ram. Old games only move a few sprites or bobs so copying them every frame to gfx ram eats too much bandwitch. I doubt that making an AGA backend would help much regarding this. Using blitter would just involve blitter performing masking operations (as long as the animation frames fit in chipram).
Using planar would be useful too.
-
I agree completely with the OP. Don't get me wrong, SDL is a great thing, but it's just plain not designed for hardware like 68k Amigas. (This is why when I do get moving on my game-dev projects for the Amiga, it's going to be all-native.)
-
68k SDL should be declared illegal ;)
There is plenty of people who already are spending lots of time to making SDL ports to 68k amigas, that just....
If they instead making 5 SDL ports, could make 1 native port, that would be much better.
And this is not actually codin, this about "how sdl is useless for 68k amigas"
-
While I do agree that it's a shame that there's little entertainment software that takes advantage of more "powerful" 68k Amigas I do understand why SDL and other less native api ports have become the main source of software for amiga based systems.
There's simply not enough coders left that know how to program specifically for the Amiga, not to mention it's more work to do so, and it's not easy to find good documentation to make amiga "native" software. SDL, Allegro, etc. however have a plethora of examples, tutorials and so on plastered all over the net. Things like gfx.lib, ahi, and so also often require more work due to the need to write a lot more own functions and whatnot vs. something like SDL (especially when it comes to games).
There's also the simple fact that more advanced games (stuff beyond stock a500/a600/a1200/etc) is a lot of work. If commercial companies from back in the day rarely made things that wouldnt today be called very retro, then its going to be hard for Joe Public to do it from his bedroom. On top of this it's *very* difficult to find people to work with that stick with things and maintain conviction. The sheer volume of work required to make a game to match the specs of a nicely upgraded amiga is either something beyond 1 person, or something that will take years.
All this said and done however, with the advent of things like minimig, natami, fpga arcade, and the fact that most people using 68k amigas have a higher base spec than yesteryear I still have hopes that maybe us 68k fans might still see a nice "amiga native" game or 2. :)
-
Oh, and in regards to ScummVM, latest 68k ports dont use sdl.
It's a shame I lost the warpsdl sdk though. Its both much faster and works with aga.
-
Great :D I need to give a try to ScummVM
-
Oh, and in regards to ScummVM, latest 68k ports dont use sdl.
Chunky2planar isn't a great idea on AGA miggies for these kind of 2d games anyway.
It's a shame I lost the warpsdl sdk though. Its both much faster and works with aga.
warpsdl was quite smooth on my miggies, what a pity. Chaozer doesn't reply any email :-(
-
My AGA/ECS ports seem to run well enough on real hw, check youtube ;)
Back to the 68k SDL, yes it is a little slow on real HW (but runs surprisingly well on OS4/MorphOS). Anyway my next RTG release won't use SDL though and should be quicker than my current version.
-
You are doing great job, your way to do is right way :)
I understand that somebody wants to get results fast or want to proof of concept, but anything SDL related cant be final solution for 68k amigas.
Is it so, that making SDL port, makes native port easier? After that it is alredy 68k and you just replace SDL code slowly to native code??? <- Question :)
My personal wish to get native would be Netsurf
-
Is it so, that making SDL port, makes native port easier? After that it is alredy 68k and you just replace SDL code slowly to native code??? <- Question :)
Maintaining port is impossible. When there is new version you have to start from scratch again.
Some projects are modular allowing you to write your own backend... but for example Freeciv 2 is huge and replacing SDL GUI with MUI is lot of work...
My personal wish to get native would be Netsurf
It still does not change the fact that Netsurf is designed for RISC OS which does not have proper multitasking and not taking full advantage of Amiga.
-
68k SDL should be declared illegal ;)
There is plenty of people who already are spending lots of time to making SDL ports to 68k amigas, that just....
If they instead making 5 SDL ports, could make 1 native port, that would be much better.
And this is not actually codin, this about "how sdl is useless for 68k amigas"
SDL proved to be quite useful for me for doing the reverse - porting my 68K native Amiga games to SDL then compiling them with ease on AmigaOS 4, MacOS X and Windows. If it wasn't for SDL then I probably would not go with the hassle to learn about MacOS and Windows coding, but now I still code on my Amiga and then recompile my games on other machines.
So, if I am going to write something serious for 68K Amigas, I will most probably do it in SDL to be able to easily port it on other machines, than having to rewrite it for SDL in later stages.
-
So, if I am going to write something serious for 68K Amigas, I will most probably do it in SDL to be able to easily port it on other machines, than having to rewrite it for SDL in later stages.
I prefer the approach of having an abstract engine for the game designed around an Amiga backend, and just adapt the backend to SDL for off-platform ports...
-
>68k software developement is totally halted, or all new software for 68k amigas is >useless SDL ports.
I dont know wy you write this for 68k
do you see on other AOS or PPC AOS more than SDL Ports ?
when we look on aminet you can see on 68k most native programs/ games that are only on amiga 68k develop and run not on Linux.
>So what kind of apps and games could theoritically run 040/060? Quite much any PC >game that that has requiremt something like 486
because of the slow amiga GFX Bus only 320*240 games.
and thats the problem.SDL get popular in Linux when PC Hardware was able to do 640*480 Pixel games in true colors, so most games run only with 640*480 and only very few of the SDL developers make their games running on 320*240 Pixels.new written SDL games need lots more Power, many of them are not very fast to run on a OS4 or MOS system.
the reason is that today pixelshader fast CPU is very very cheap.Most users have them now.
And write programs for slow hardware cost lots more programing time.time is short, but if you have time maybe you can do new games that run on slow hardware.But i guess if you maybe learn to program you like to buy a cheap CP for 300 Eur and code on this the program.you save time to speed optimize or live with ugly graphic ;-)
that sdl does not slowdown, you can see when you look at the speed of netsurf.68k version is more than 3* faster with SDL.
tha only problem is the Amiga GFX bus access is too slow to transfer the data of a 640*480 screen.
when you want render 640*480 16 bit screen with 25 fps you must transfer 15 megabyte /sec.
But mediator with a Voodoo 3 transfer only 8 megabyte /sec.
The CPU is fast enough, only a faster GFX Bus is need.
hope that natami come some day, then can see that SDL games run lots faster due to faster GFX Bus.
-
Netsurf SDL problem for me is that it requires true type fonts.
Amiga chip / zorro bus is sure slow, but have you tried FBlit? Games like simcity 2000 and napalm get huge speed up to vertical/horzontal scrolling with it, if you promote them to fast mem with FBLit.
But ofcourse there is limitations with 68k amigas, programmers just neet to live with them.
-
But ofcourse there is limitations with 68k amigas, programmers just neet to live with them.
Which only means that if you want to do certain things, you simply have to do them right ;)
-
True :)
-
Talking about 68k apps and games, sound many time like it would be impossible to do anything to 68k amigas. Wich makes me wonder, how good they were, I mean those who made amaizing apps and games to amiga years ago?? Were they humans or some kind of super creatures with big brains and super natural skills?????
-
Talking about 68k apps and games, sound many time like it would be impossible to do anything to 68k amigas. Wich makes me wonder, how good they were, I mean those who made amaizing apps and games to amiga years ago?? Were they humans or some kind of super creatures with big brains and super natural skills?????
Even a stock A500 is a pretty capable machine. The problem is that a lot of these projects are written for modern machines, and aren't really designed around the limits of the hardware, so even using native hardware/firmware access is only going to get you so far. Certainly there were Amiga coders back in the day who dazzled with raw skill, but a large part of why things seemed to work so well is that programmers were willing to tailor and compromise their designs in order to work well on the hardware. Which is why, as I said, my approach would be to design a game for the Amiga and port it to other systems afterward - it's a lot easier to take a program from a less-powerful system onto a more-powerful one than vice-versa.
-
Netsurf is designed to run 16mhz system, is it low-end enough :D
Would be smart to try to find and maybe do some co-operation from Risc OS / Atari scene, there is many projects on
-
Talking about 68k apps and games, sound many time like it would be impossible to do anything to 68k amigas. Wich makes me wonder, how good they were, I mean those who made amaizing apps and games to amiga years ago?? Were they humans or some kind of super creatures with big brains and super natural skills?????
A large part of the difference is the file sizes of the graphics data. Graphic images today are much larger than images of yesteryear, so 68k Amigas did not have to process large image files. Had the Amiga graphics and bus speeds advanced, it would not be as much of a problem today. The bus speeds would be able to process the larger image files of today. An alternative would be to find more efficient means/format of storing image data.
-
One thing to you reconsider
There is at least two different new 68k systems to becoming. I believe that both of them could have great benefit from native Netsurf.
Modern web brovser is essential to any system and makes your system more the present day
Arthur has kindly released sources of Netsurf SDL to aminet and don't forget that Chris has also promised to help
*Chris has made OS4 port of Netsurf
To get rid of SDL is not just a speed it is also feel of native app. Reaction/Mui gui would give it the feel of the original amiga app
-
Talking about 68k apps and games, sound many time like it would be impossible to do anything to 68k amigas. Wich makes me wonder, how good they were, I mean those who made amaizing apps and games to amiga years ago?? Were they humans or some kind of super creatures with big brains and super natural skills?????
The problem is that SDL is generic, and written in C. To get the most out of the Amiga, you would use assembler, and the tricks the Amiga provides to speed things up.
For example, in a web browser you could have a 64x640 'screen' with it's own palette for your navigation buttons (and could even run it at a different resolution to the webpage viewport itself). You could then run the actual viewport in a sliced mode for more colours etc. Such things would be difficult to add to a ported project.
-
Talking about 68k apps and games, sound many time like it would be impossible to do anything to 68k amigas. Wich makes me wonder, how good they were, I mean those who made amaizing apps and games to amiga years ago?? Were they humans or some kind of super creatures with big brains and super natural skills?????
It is pretty difficult squeeze true colour JPEG graphics with tons of Javascript into Amiga 500. Even simple tasks like decoding JPEGs is very slow on anything less than 68060 and quality is still quite poor on some 640x200 with 16 colours...
-
>Certainly there were Amiga coders back in the day who dazzled with raw skill, but a large >part of why things seemed to work so well is that programmers were willing to tailor and >compromise their designs in order to work well on the hardware.
that always happen.there is still no Hardware out that is fast enough to run all in that way designers want.also remember the play consoles.
But in the past, amiga Hardware Limits are state of the Art and most users have it.so games are develop for amiga in 32 colors enhanced with copper lists to more color instead of EGA 16 color of PC.
but later PC get faster and faster users buy them more and PC market grow..devleopers see less limits on PC or game consoles and so go to PC or game consoles and di more complex games.
and so nobody want to strip down something that it run on a AOS.nobody pay enough money for the stripdown.
If this is 68k or MOS or OS4.All ist too slow in compare to modern Systems as playstation 3 or xbox 360 or PC and have only a market of a few hundret users.
Netsurf is designed to run 16mhz system, is it low-end enough :D
but the problem is, the internet pages today are not designed to run with 16 MHZ well.
Pages use CSS truecolor images, lots images and some other performance huge features.and if the web designer use no A500 to develop the page, he did not notice that his page is show too slow.
if you want show only a simple html page with text antialiasing netsurf is fast and can show such a page in below 1 sec.try it out with the ibrowse history.html file
-
Netsurf SDL problem for me is that it requires true type fonts.
Amiga chip / zorro bus is sure slow, but have you tried FBlit? Games like simcity 2000 and napalm get huge speed up to vertical/horzontal scrolling with it, if you promote them to fast mem with FBLit.
But ofcourse there is limitations with 68k amigas, programmers just neet to live with them.
all does not help, because the simple fact, the screen resolution used in modern games is 640*480*16 bit at least.
nobody enhance the images for 8 bit usage and 256 color.
and so its a simple calculation.to run a 640*480 * 16 bit image game at same speed with full scrolling as a 320*240*8 bit image game, you need a Hardware that is 8* faster.
I dont know what the Problem is for you with truetype Fonts.
speedtests on large Text html files show, that antialias truetype fonts do things not slowdown.so the internal fonts version is not need
the CPU expensive stuff is loading and decoding the jpg process the page with CSS.
when you use a page without CSS and big images all go faster.
-
To get rid of SDL is not just a speed it is also feel of native app. Reaction/Mui gui would give it the feel of the original amiga app
Yep, with a native gui you would get things like menuitems and scrollbars visible with any screenmode (now they're cut off on anything < 1024*768). But would the program itself be any faster ? Perhaps it just feels faster because it's native.
-
Quite many SDL apps are slow 68k amigas, even when they shouldn't be.
-
>Yep, with a native gui you would get things like menuitems and scrollbars visible with any >screenmode (now they're cut off on anything < 1024*768).
you need press the resize button.then the scrollbars are set correct.
>But would the program itself be any faster ?
the SDL Port is when look at performance /MHZ lots faster as on OS4, so seem no speedup possible.
See here the time results.
http://www.amiga.org/forums/showpost.php?p=649724&postcount=146
but its intresting to see how fast it is in performance /MHZ on a Acorn RISC OS.
>Quite many SDL apps are slow 68k amigas, even when they shouldn't be.
I can only repeat the Fact, when a game developer develop his game for full scroll in 640*480 16 bit or at larger screen resolution, the data is too much for a Amiga.
another big problem is audio.old amiga games music have only samplerate of 7 khz and 4 channels.
but most games today use more than 4 channels and at least a sample rate of 22 khz but most 44 khz.
So you need all sounds convert to 7 khz and that sound is ok if only 4 channels are use.
wy you do not learn a little programming, and change all graphic and game coordinates in a program so it can show on 320*240 16 bit screen.
this is possible.
then a sdl game is too playable on classic.
On the othe side when you just use a SDL game as it is and try it without use of SDL, the game is still lots too slow.the screen resolution or audio channels are lots too much for a classic
So we need only guys who have time that strip down SDL games to 320*240 16 bit screen and 4 channel audio with 7 khz.
-
68k Amiga Os is usually hevily patched, so problem is that every patch does some small incompatibility to it and many times it is really difficult solve this kind of problems because many problems are caused interaction of several patches.
So I just woun't install afa os or tt engine. I want to keep my OS lightly patched.
Situation would be different when 68k aros is mature enough to be usefull, I hope. No need to run dozens of patches to get os more prety/usefull/modern.
About speed, I really do belive that SDL is major slowdown for 68k amigas, but we will see is it true, when native scummVM is relased.
It is simply not possible that SDL kind of generic engine would be optimized enough to such low spec machines as 68k amigas are and still be compatiable to high spec machines.
-
@utri007
SDL often assumes that the systems it supports have chunky graphics modes. Chunky graphics are consistently faster than planar at almost every operation. The only time planar can outperform chunky is at low bit-depths. Odd bit-depths like 32 colors (5 bits-per-pixel) would also be impossible without bitplanes.
If this is about the NatAmi or the FPGAArcade being slowed down by SDL, I assure you that it will be possible to optimize to those systems by using their native chunky-pixel support.
Things to note: SDL 1.2.14 and earlier used software CPU blitting at most resolutions while the experimental 1.3 versions due for release soon rest heavily on OpenGL and require 3D accelerated texturing to do such things as image rotations. Also SDL 1.3 is under a more liberal license than the earlier versions.
As such, many of the problems you fear will come to pass will not affect the final version of the NatAmi. It will affect only the earlier Amigas due to their dependence on bit-planes.
-
>Yep, with a native gui you would get things like menuitems and scrollbars visible with any >screenmode (now they're cut off on anything < 1024*768).
you need press the resize button.then the scrollbars are set correct.
This doesn't work.
-
About speed, I really do belive that SDL is major slowdown for 68k amigas, but we will see is it true, when native scummVM is relased.
Quite a few RTG 060 users have said the AGA version of ScummVM is much faster on their RTG boxes than the SDL based RTG release so yes, I hope when I do a 'native' RTG version we'll see the speed increase a bit (it should of course run faster than the AGA version at the same resolution/color depth).
The AGA version may get a chance to catch up again with the RTG version if I can get direct-chunky working (eg Graffiti) and skip the C2P step ;)
I don't think the 68k SDL is a curse though, it was very helpful to me when I did my intial port (the 68k SDL source code was made open source). Most of the performance issues are probably down to the fact that it's no longer maintained.
-
Quite a few RTG 060 users have said the AGA version of ScummVM is much faster on their RTG boxes than the SDL based RTG release so yes, I hope when I do a 'native' RTG version we'll see the speed increase a bit (it should of course run faster than the AGA version at the same resolution/color depth).
The AGA version may get a chance to catch up again with the RTG version if I can get direct-chunky working (eg Graffiti) and skip the C2P step ;)
I don't the 68k SDL is a curse though, it was very helpful to me when I did my intial port (the 68k SDL source code was made open source). Most of the performance issues are probably down to the fact that it's no longer maintained.
On both cgx/p96/sdl you could lock the bitmap and draw directly to it, most of times you'll get a nice speedup (although with SDL you may have slowdowns compared to cgx/p96 if you use doublebuffer functions). If you could tune up rendering to write chunks of 4 or more pixels it would be even faster :-)
-
nother big problem is audio.old amiga games music have only samplerate of 7 khz and 4 channels.
but most games today use more than 4 channels and at least a sample rate of 22 khz but most 44 khz.
So you need all sounds convert to 7 khz and that sound is ok if only 4 channels are use.
Amiga sample playback is at 28khz. If you open and close a double scanned screen, that allows 56khz playback. Also, even the A500 is capable of channel mixing.There have been 8 channel MOD's since the late eighties. The problem as I have mentioned, is that ports from other platforms do not use Amiga tricks to increase the speed/quality of sound and graphics fidelity.
-
Quite a few RTG 060 users have said the AGA version of ScummVM is much faster on their RTG boxes than the SDL based RTG release so yes, I hope when I do a 'native' RTG version we'll see the speed increase a bit (it should of course run faster than the AGA version at the same resolution/color depth).
The AGA version may get a chance to catch up again with the RTG version if I can get direct-chunky working (eg Graffiti) and skip the C2P step ;)
I don't the 68k SDL is a curse though, it was very helpful to me when I did my intial port (the 68k SDL source code was made open source). Most of the performance issues are probably down to the fact that it's no longer maintained.
scumm games are no action games that need frequently update all graphic.How is it possible to measure the speedup ?
a better test to compare between a native port and sdl is maybe quake
try a test with sdlquake and quake.set your workbench to 8 bit to run sdlquake.fullscreen do not work on old SDL
fullscreen 640*480 8 bit screen.
or use window mode so it run on workench in quake68k.
http://aminet.net/package/game/shoot/sdlquake-1.0.9
http://aminet.net/package/game/shoot/Quake68k
free shareware files are here.You need a PC to install it and then copy the wad files.
http://quakeone.com/freequake/en.html
and presse esc and go to menu option and choose open console
Now type in console
timedemo demo1
this you can do in both quake and you get a fps value.what results you get with native Port and sdl port ?.you van also test on AGA.here can see that AGA is unusable slow
And if sdlquake is really slower as native version, i compile it with newest sdl, this is faster as the old sdl that is used in this port, and fullscreen can work too
I often see that think something is faster, but when measure time no speedup can notice.
A good example you can see on netsurf thread(link above).first it was report, older netsurf is faster as new netsurf.but when the user measure time he see that new netsurf is lots faster.
maybe its really possible to speed up without SDL around 50%, but thats near nothing and nobody notice it, when remember that new games have more than 8* more graphic data and more sounds date, the game is still unplayable if it use SDL or not.
>This doesn't work.
ah yes i see on new netsurf is because of gadgets not possible to use smaller screens as 1024.maybe you write to Artur, if he have add the limit, and if so he can remove.
but currently most pages need 1024 show in full width and you need not scroll in X
I test on a older netsurf, and when use 800*600 with amiga.org, you can not see all in width.
so also for amiga pages 1024 width is good
-
On both cgx/p96/sdl you could lock the bitmap and draw directly to it, most of times you'll get a nice speedup (although with SDL you may have slowdowns compared to cgx/p96 if you use doublebuffer functions). If you could tune up rendering to write chunks of 4 or more pixels it would be even faster :-)
sdl is able to work in same way as you told, when use HWSURFACE.but then many modern games run slower.
todays games use alphachannel for all objects.
this mean before calc a pixel, the pixel data need read, the object data is add and then the pixel is written.
but because amiga GFX card access is so slow, and a gfx card read is more slower than write, this slowdown alot.
-
Amiga sample playback is at 28khz. If you open and close a double scanned screen, that allows 56khz playback. Also, even the A500 is capable of channel mixing.There have been 8 channel MOD's since the late eighties. The problem as I have mentioned, is that ports from other platforms do not use Amiga tricks to increase the speed/quality of sound and graphics fidelity.
try a old amiga game and a sample ripper.in winuae you can too rip samples-
you see sample rate is not often larger as 7 khz, because on A500 memory was low and memory need save
also transpose a sample with paula have very ugly sound quality.amiga have a 7 khz filter so it sound not so ugly as when disable the filter.
modern systems as sdlmixer use linear transpose this cost more CPU power but have good sound quality so you can get CD quality sound
so the first thing you can do, when you want play a sdl game on a slow amiga, is switch music and sound off.
-
todays games use alphachannel for all objects.
this mean before calc a pixel, the pixel data need read, the object data is add and then the pixel is written.
but because amiga GFX card access is so slow, and a gfx card read is more slower than write, this slowdown alot.
It is only slow if you dont have HW accelerated alpha blits.
-
Nobody who have common sense doesn't drem to play halflife with his/her 68k amiga.
There is no modern games for 68k amigas and woun't be. But still... still, amiga is hobby amchine and it is perfectyly possible play games with 320x256 resolution and some strategy games with 640x512 resolution.
It would be nice to use Netsurf with screen 640x512 and 256 colors or maybe even 64 colors. It should work any amiga wich has enough memory. Reducing palette would make memory requirements slower also.
Web browser is tool, so I don't dream to read days pappers with with my 68040/40mhz/64mb/Aga machine, but quite often I want to do/donwload something with it.
I F we are looking games/apps to port to our beloved amigas, we should look projects from 90 centry
Like:
http://liberatedgames.com/
http://www.dmoz.org/Computers/Systems/RISC_OS/Software/Games/
AMiga.org members has also dozens of abandoned projects, so it would be smart to ask projects here. IF somebody want to do something and don't want to start from scratch
-
sdl is able to work in same way as you told, when use HWSURFACE.but then many modern games run slower.
If you use SDL doublebuffer functions even if you enable HWSURFACE it will run slower than cgx using double buffer functions (at least on UAE).
todays games use alphachannel for all objects.
this mean before calc a pixel, the pixel data need read, the object data is add and then the pixel is written.
That depends on the game generation and the coder. Reading from gfx ram is slow even on pc so it's better to perform the calculations in ram and write the pixels with the new value directly.
There are decent games like Diablo, Age of Empires or Starcraft that run happily on a 640x480 8bit screen.
but because amiga GFX card access is so slow, and a gfx card read is more slower than write, this slowdown alot.
The problem is coding 2d games using graphic card as a big framebuffer instead of taking advantage of accelerated blitting and scrolling. And the problem for modern games is that you could be using Warp3D to move 2D images using hardware resources instead of transfering one dozen of megabytes per second. Just upload your gfx to RTG ram configured as textures and move them using Warp3D instead of cpu: you'll reduce bus bandwitch required to move the gfx and will require a less powerful cpu
a better test to compare between a native port and sdl is maybe quake
what? sorry, I strongly disagree because Quake on classics is mostly cpu limited and its use of SDL is limited to:
a) locking display bitmap, writting the pixels directly to gfx ram or...
b) performing a raw copy (just like WritePixelArray on RTG)
so there's hardly any difference with CGX code. Any difference in performance could be due SDL handling of double buffer/vsync in a different way but it's caused by the SDL port. A better test would involve using SDL blitting functions, instead of simply copying raw data through amiga bus to rtg ram.
-
try a old amiga game and a sample ripper.in winuae you can too rip samples-
you see sample rate is not often larger as 7 khz, because on A500 memory was low and memory need save
also transpose a sample with paula have very ugly sound quality.amiga have a 7 khz filter so it sound not so ugly as when disable the filter.
modern systems as sdlmixer use linear transpose this cost more CPU power but have good sound quality so you can get CD quality sound
so the first thing you can do, when you want play a sdl game on a slow amiga, is switch music and sound off.
Who's talking about the A500? who in their right mind would try running SDL on such a platform? Also, much of the OCS limitations came from lack of storage space, not bus throughput. I quite happily play 14bit multi channel ADPCM music on my A1200/030, and it sounds brilliant. And the machine has plenty of bandwidth for other tasks.
The first thing you want to do if you play a game on Amiga is not use SDL, and use as many amiga hardware tricks as you can. Many Amiga demo's run in HAM modes and have 14bit sound. SDL would not allow this on such a limited platform, and I would it even allow you to reach such a low level? I doubt it.
-
>The first thing you want to do if you play a game on Amiga is not use SDL, and use as >many amiga hardware tricks as you can. Many Amiga demo's run in HAM modes and have >14bit sound. SDL would not allow this on such a limited platform, and I would it even >allow you to reach such a low level? I doubt it.
I do now compare on my winuae system and notice the SDL version is only 10 % slower.in numbers it is 91 fps sdl_quake and 99 fps quake68k on a 1920*1080 fullscreen 8 bit
so there is no hope that you can
>There are decent games like Diablo, Age of Empires or Starcraft that run happily on a >640x480 8bit screen.
this are not so speed critical stuff, as a action shooter or jump and run with scrolling.
If there is a SDL version here, then there are good chances that it is playable, maybe with low samplerate
>I quite happily play 14bit multi channel ADPCM music on my A1200/030, and it sounds >brilliant. And the machine has plenty of bandwidth for other tasks.
can you post a link of such a song and player ?.and the 7 khz filter of your amiga need set to off.have you hear the music over headphone or a good stereo sound system ?
maybe with the 1084 monitor speakers it sound ok, but with a good loudspeaker it sound very bad.
for amiga the only player which can do good quality is octamed soundstudio when you enable in mixing routine stereo and filter and can reach better quality.but then a simple 4 channel song use full cpu load on a classic.try it out, if you not believe.
but its possible to change sdl mixer that it do crappy nearest soundmixing to be faster.maybe there is a option so nearest sound mixing is possible.
but this give only little speedup, actual games are design that there are at least 11 channels here.11 channels is the default of sdl_mixer.if a developer need more he can enhance.
@Itix
>It is only slow if you dont have HW accelerated alpha blits.
As far i know no 2D gfx card have HW accelerated alpha blits.Or do you know any for amiga ?
today OS use 3D features of GFX Card for that.
@Crumb
>what? sorry, I strongly disagree because Quake on classics is mostly cpu limited and >its use of SDL is limited to:
>a) locking display bitmap, writting the pixels directly to gfx ram or...
>b) performing a raw copy (just like WritePixelArray on RTG)
thats true, netsurf SDL work the same way, but when you look how games work, then you see that code do only copy some bytes to gfx buffer.
and this copy operations are limit by GFX Bus access.
sdl is very fast, it convert any bitmap format to screen bitmap format.
if somebody want write a game for amiga RTG, he must write code for do this.P96 or CGX functions are not so fast, because i test what happen when i use instead of SDL blit operations the CGX functions direct.was slower seem CGX do also have more calling overhead.a simple 1 pixel blit was slower in P96 too
also SDL use runlength encoding for 1 bit alphamasks and prepare the images to faster blit.this is too faster, it avoid lots of mem access and check for mask operations
and when you write a game that run on RTG you have of course no copper or can do some display tricks smooth scroll etc.
-
Having recently set up amithlon again Im thankful for SDL and the software it bring to a more powerful "68k amiga" system, but I love my a1200+40mhz appollo '040+32 meg as well.
While such a system is humble in modern terms there's still potential there that was unfortunately never really tapped. Yes there's games that can take advantage of faster hardware, but only really fps and other 3d games, nothing to push the strengths of an '030 upwards +fast ram based aga machine in the way shadow of the beast, elfmania, super stardust,etc. push a 7-ish mhz 68000 +ocs/ecs or 14ish mhz 68ec020 +aga respectively.
There's plenty of gaming styles that the amigas hardware lends itself nicely to. Just look at its catalogue. Chances are there's at least a few classic amiga games that everyone would like to see (for more random examples) upped from 16/32 colors to 64/128, sound enhanced, a few extra nice gfx effects, full speech, extra animation and a bunch of other quite feasible "enhancements".
If nothing else maybe this untapped potential (for games) of expanded aga machines will motivate me to make a "serious" classic amiga game :)
-
>The problem is coding 2d games using graphic card as a big framebuffer instead of taking >advantage of accelerated blitting and scrolling. And the problem for modern games is >that you could be using Warp3D to move 2D images using hardware resources instead of >transfering one dozen of megabytes per second. Just upload your gfx to RTG ram >configured as textures and move them using Warp3D instead of cpu: you'll reduce bus >bandwitch required to move the gfx and will require a less powerful cpu
thats theory, who have a fast RTG system that is able to use warp3d ?
when you use SDL 3D Games then all can do with GFX card.but when 3d games are written for SDl, PC have speed at 500 MHZ and more and much faster GFX bus and no limit of 256 Pixel texture size of Voodoo 3.
wawa have work much to port some usable 3D games to classic.but the 256 pixel texture limit was the problem in voodoo 3 and the limit mem in compare to modern systems, because every game use a background texture of screen resolution.this mean at least 640*480.
and last very few users own a voodoo 3.most users have a GFX card with only 2 or 4 megabyte of RAM.thats too few
I have written a game engine for amiblitz and storm mesa, but nobody write a fast working game for it, and Thilo choose his own 2d engine that can do some blits on 2d Card.
but also this is not able to play a modern game fast on a classic.for example the game amega one
http://www.a1k.org/forum/showthread.php?t=18578
or panzers
http://www.a1k.org/forum/showthread.php?t=14115
is too slow to play on 640*480 on classic
any help is welcome to make this games playable on a classic.in amiblitz you can write asm code and some routines are asm optimized.but if the GFX bus can not transfer more data is the main problem
-
>There are decent games like Diablo, Age of Empires or Starcraft that run happily on a >640x480 8bit screen.
this are not so speed critical stuff, as a action shooter or jump and run with scrolling.
Well, if your scrolling is not hw accelerated and blitting functions are non existant you´ll also depend on bus bandwitch unless you have some gfx memory to store some parts like backgrounds and draw them using blitter.
>I quite happily play 14bit multi channel ADPCM music on my A1200/030, and it sounds >brilliant. And the machine has plenty of bandwidth for other tasks.
can you post a link of such a song and player ?.and the 7 khz filter of your amiga need set to off.have you hear the music over headphone or a good stereo sound system ?
Do you use the horrible audio filter? I never met anyone who liked it :-) there are plenty of players that will allow you to output more than 7Khz sounds (e.g. HippoPlayer). In fact many games use higher frequency sounds.
Use paula directly at 28Khz 8bit instead of AHI and you´ll get a nice speedup.
@Crumb
>what? sorry, I strongly disagree because Quake on classics is mostly cpu limited and >its use of SDL is limited to:
>a) locking display bitmap, writting the pixels directly to gfx ram or...
>b) performing a raw copy (just like WritePixelArray on RTG)
and this copy operations are limit by GFX Bus access.
On Amiga it´s limited by cpu speed, not bus access. If you use AGA or a CV64 you won´t see much difference. If you are talking about emulators... well, uae behaviour will be different than a real Amiga.
sdl is very fast, it convert any bitmap format to screen bitmap format.
if somebody want write a game for amiga RTG, he must write code for do this.P96 or CGX functions are not so fast, because i test what happen when i use instead of SDL blit operations the CGX functions direct.was slower seem CGX do also have more calling overhead.a simple 1 pixel blit was slower in P96 too
Are you talking about real Amiga with real CGX/P96 drivers or WinUAE p96 driver that draws all the stuff in memory and later copies the graphics to the graphic card? I mean: I don´t believe blitting a rectangle in the screen with SDL on a real Amiga is faster than copying it using real blitter with CGX functions. With a CV64/CV3D/Picasso4/AnythingPCI? I seriously doubt it. WinUAE results are FAKE because the p96 driver doesn´t act like a real Amiga driver. BTW, I hope you don´t mean you tried to blit a 1pixel x 1pixel bitmap with p96, that would be useless and ridiculous... why would you want to do that? use 8x8 or 16x16 at least.
and when you write a game that run on RTG you have of course no copper or can do some display tricks smooth scroll etc.
You can use ScrollVPort() to change the base address of the screen even with RTG cards, and you can also design your game to maximize the use of rtg blitter and avoid touching the bus as much as you can: load the most (recently) used graphics in graphics memory and use blitter to draw backgrounds and so on.
you can also keep a copy of the graphics in fastram to avoid reading and just compose the parts you need and update only the parts with transparent graphics on top. If that sounded problematic you could use MMU to mark what parts you need to transfer and which ones you don´t.
If we talk about 3D games you should simply use Warp3D or OpenGL and avoid software rendering. And if we talk about games using 3d card you could use it for 2d stuff too: Kas1e and Karlos have done that, the former with his mag and the later with his small apps.
Classic Amiga results != WinUAE results
-
>The problem is coding 2d games using graphic card as a big framebuffer instead of taking >advantage of accelerated blitting and scrolling. And the problem for modern games is >that you could be using Warp3D to move 2D images using hardware resources instead of >transfering one dozen of megabytes per second. Just upload your gfx to RTG ram >configured as textures and move them using Warp3D instead of cpu: you'll reduce bus >bandwitch required to move the gfx and will require a less powerful cpu
thats theory, who have a fast RTG system that is able to use warp3d ?
Anyone who has a Mediator for example.
when you use SDL 3D Games then all can do with GFX card.but when 3d games are written for SDl, PC have speed at 500 MHZ and more and much faster GFX bus and no limit of 256 Pixel texture size of Voodoo 3.
Quake2&Wipeout run fine on my A4000. For 2D stuff 256x256 tiles are not a problem.
wawa have work much to port some usable 3D games to classic.but the 256 pixel texture limit was the problem in voodoo 3 and the limit mem in compare to modern systems, because every game use a background texture of screen resolution.this mean at least 640*480.
With all my respect to wawa, recompiling pc games is not the same as developing native ones designed to run on Classic Amigas with Warp3D or MiniGL.
and last very few users own a voodoo 3.most users have a GFX card with only 2 or 4 megabyte of RAM.thats too few
Most of Mediator/GREX/Prometheus users have Voodoo3 with 16MB. That´s enough to make good games.
any help is welcome to make this games playable on a classic.in amiblitz you can write asm code and some routines are asm optimized.but if the GFX bus can not transfer more data is the main problem
If you want to have good results on classics you can´t simply treat them as a PC even if you use a RTG card: you have to design your engine to avoid copying to graphics mem as much as you can, just load the most used graphics at the beginning and transfer through the bus the least used and smaller ones. WinUAE probably won´t give you the right impression about the real bottlenecks.
-
SDLquake is surpizenly fast
060/66mhz/RTG
With same colordepth and screen size clickboom's quake is 2,5fps faster
040/40mhz/AGA
Clickboom's quake is more than 3fps faster, actually clickboom's quake is almost as fast than SDLquake 060 8,5fps/9,1fps
On 060 both are playable with a little patience, but on 040 system 3fps is difference between totally unplayable and playable.
So when will SDL Netsurf support amiga fonts and 8bit screens??
-
Conclusion:
SDLquake is 37%-22% less speedy than clickboom's quake
Such a low spec machines every frame is important. Good result any way, I would ques that it is much more worse.
-
Conclusion:
SDLquake is 37%-22% less speedy than clickboom's quake
With or without hardware Warp3D support? Since Bernd's version of SDL uses StormMesa->Warp3D, that could make a huge difference. The CPU and gfx card could also make a large difference to the percentage. It would be more useful information to post your specs and settings with the results.
Such a low spec machines every frame is important. Good result any way, I would ques that it is much more worse.
Yea, a couple of frames per second difference is a lot when below 15 fps. There are plenty of possibilities for speed up of that amount. CyberPatcher type "missing" instruction patches can be valuable on 68040 and 68060 and CopyMem and other system patches and enhancements can help with 2D or 3D. For Warp3D hardware acceleration, there is faster 68k enhanced Warp3D libraries (originals are poorly optimized) and setting the Queue size larger in indirect mode (default with StormMesa and SDL I believe) with an environmental variable can help significantly. QuakeGL/BlitzQuake in 640x480x16 runs at good speed once the textures are cached on my 060@75MHz Amiga. The slow Mediator bus speed isn't as much of an issue then. Fast games are certainly possible at 640x480x16 on high end Amigas but usually require some attention to optimizing and most Amiga compilers don't generate very optimal code.
-
Clickboom's quake doesn't do warp3d. I belive that with warp 3d support result would similar, ie. sldquake / glquake
It is 060 version, it much faster than original exe with 040 also.
Bern is author of SDL version of Netdurf, so in this case 3d tests are useless.
Maybe 80% todays classic amigas has at least 030 and 64mb ram? Maybe 50% has 040/060 with at least 64mb ram? 40% has a somekind of RTG card? 20% has a mediator or similar with at least 8mb ram on their garphics card?
-
today OS use 3D features of GFX Card for that.
Is it a problem? There are 3D gfx cards for Amiga.
-
Yeah, but how many people have one? I didn't even have an RTG card until fairly recently.
-
Clickboom's quake doesn't do warp3d. I belive that with warp 3d support result would similar, ie. sldquake / glquake
Hardware 3D support gives a significant speedup. Here are my results with CSMK3 060@75MHz and Mediator with Voodoo 4 but no Cyberpatcher type patcher...
640x480x16
-----------
Frank Wille's Quake 3-4 fps
Clickboom Quake060 4-5 fps
QuakeGL 20-25 fps (looks best too)
640x480x8
----------
Frank Wille's Quake 4-5 fps
Clickboom Quake060 5-6 fps
QuakeGL No 8 bit hardware 3D support on Voodoo 3+
Hardware 3D acceleration does matter. It's probably more important with a slow bus.
It is 060 version, it much faster than original exe with 040 also.
It's not that most compilers do a good job of optimizing for the 060 but rather that 040 compiled code doesn't run very well on the 060.
Bern is author of SDL version of Netdurf, so in this case 3d tests are useless.
Yea, 3D hardware acceleration isn't going to help much with Netsurf unless it can be used like kas1e does for his disk mag which is fast and nice on the Voodoo.
Maybe 80% todays classic amigas has at least 030 and 64mb ram? Maybe 50% has 040/060 with at least 64mb ram? 40% has a somekind of RTG card? 20% has a mediator or similar with at least 8mb ram on their garphics card?
Those are plausible guesses of what power classic Amiga users use. Hopefully the new fpga Amigas will help out those numbers and give some additional 3D accelerated hardware options.
-
Good target system would be 030/040, 64mb ram and 2mb graphicscard/AGA.
There is plenty of app/games for 020/8mb and AGA. There is even more apps/games for systems like 060, 64mb ram and 16mb voodoo than those specs that I just suggested.
It seems that the games are either 020/8mb or 060/128mb/3d, middle level amigas has completely forgotten
There is no point to argue, how thing should do with modern systems, because most of us don't have 3D and 68k Amigas isn't modern hardware. Thats why SDL sucks with 68k Amigas
-
Yeah. Speaking for myself, I have an A3000 with a 28MHz G-Force 040 accelerator, 8MB accelerator RAM, 8MB motherboard fast RAM, 2MB chip RAM, and a 2MB RTG card. Aside from perhaps a simple sound card and maybe a 40MHz 040, this is as much as I'm likely to ever have, as the Amiga is just a hobby for me, not something for which I could justify the prices high-end accelerators with lots of RAM command. Of course, I don't think people should be obligated to target my system, but it would be nice to see some more Amiga development for something less than the creme de la creme (to say nothing of the poor neglected unexpanded OCS Amiga.)
-
Nobody who have common sense doesn't dream to play halflife with his/her 68k amiga.
Ah sure. It might work with 8 bit graphics.
Bernd_afa: have written a game engine for amiblitz and storm mesa, but nobody write a fast working game for it, and Thilo choose his own 2d engine that can do some blits on 2d Card.
Is your engine publicly available? If so, then where? I wouldn't mind doing some experimenting with it.
-
You should add more ram to your system. I do understand that amiga is hobby machine, but hobbies cost. Does it require GVP sims or can you use standard 72 pin sims? It would be about 200$ to get 64mb to your accelerator with GVP sims, but I'm sure that you woun't repent it.
-
You should add more ram to your system. I do understand that amiga is hobby machine, but hobbies cost. Does it require GVP sims or can you use standard 72 pin sims? It would be about 200$ to get 64mb to your accelerator with GVP sims, but I'm sure that you woun't repent it.
1MB GVP SIMMs only. I'd have to swap out the accelerator entirely to get it above 8MB. $200 is within reason for the occasional purchase, but the fact is that I just don't use my Amiga for enough to justify spending that money on a RAM expansion instead of, say, buying a few games or saving towards another interesting old system. 18MB should be plenty for a lot of purposes, certainly for a lot of non-3D gaming, but with so many programs that are just PC ports via SDL that bring with them PC expectations of RAM capacity and CPU horsepower, not so much.
-
Bern is author of SDL version of Netdurf, so in this case 3d tests are useless.
I am not the author of netsurf SDL.Artur do a alot and great work on netsurf to add features that netsurf sdl version(in mains source do not have).In newest netsurf artur use agar GUI for GUI in some gadgets
http://libagar.org/
, i do not like the mix, i have told Artur, because i fear some hang problems due to message lost.I am not familar with that
But the sdl version can better update with new core, and if the standard core not run on amiga, i help Artur.
All other do Artur alone in great work.He have done lots work to bring a browser to amiga.
when no Artur was here, i only compile from time to time the sdl version and release it and before no java script is in, i do not do any work to enhance it.
-
Ah sure. It might work with 8 bit graphics.
Is your engine publicly available? If so, then where? I wouldn't mind doing some experimenting with it.
its in sourceforge for amiblitz 3.it work in amiblitz 3, there is a demo in the amiblitz3/sourcecodes/includes/gl.bb2 include.
amiblitz execute the example if the file is not include and is use standalone.
see here the syntax of that example program.its easy to bring 2d games to 3d, because you can choose a virtual coordinate system.I decide to use stormmesa, but native PPC stormmesa do not work with new OS4 warp3d.because OS4 devs remove a feature in warp3d that stormmesa need.If it work on MOS, i dont know, because no intrestet user have MOS and want test.
The code below produce this testimage.later version should load milkshape objects make out of 2d easy 3d with depthmap etc.but because stormmesa is not go to a standard GL API, i give up, because i dont want do special native versions.and thilo do continue his 2d engine
CNIF #__include=0
;Amiblitz 2 test for opengl
Syntax 2 ;the relax declare mode
optimize 7
WBStartup
.begin
width.l=320:height.l=200
gl_init{width,height,16,0} ;the screen open
gl_2dview{640,480} ;need to set coord leftedge=0 rightedge=640 and hold size of pics
;depent on this resolution
;topedge=0 and buttom edge=480
;on default ogl use leftedge=-1 rightedge+1 top +1 buttom -1
gl_load {0,"data/pattern"}
; Stop
gl_load {1,"data/ball64x64",0}
gl_load {2,"data/reflect.jpg",0}
gl_load {3,"data/times32.png",0}
gl_sphere {4,40,0,15,15} ;create the sphere at beginning for more speed.But possible on all place
gl_cylinder{5,110,30,50,0,15,15} ;a cylinder with texture 0
gl_cylinder{6,110,30,50,2,15,15} ;another cylinder for the reflection with texture2
gl_quad{7,50,50,50,0}
gl_quad{8,50,50,50,2}
.startvals
zval.f=0:xval.f=320:yval.f=240:trans.f=255:yvallight.f=yval:rot.f=6:tsize.f=1:rot.f=84
Repeat
ev.l = Event
Select ev
Case #IDCMP_RAWKEY
Select EventCode
Case $4e : xval+10
Case $4f : xval-10
Case $4c : yval-10
Case $4d : yval+10
Case $13 : rot.f+6
Case $45 : ev=#IDCMP_CLOSEWINDOW
End Select
Select EventVanillaKey
Case @"q" : zval-10
Case @"a" : zval+10
Case @"t" : trans.f+10
Case @"g" : trans.f-10
Case @"m" : tpos.l+2
Case @"Q" : yvallight.f-10
Case @"A" : yvallight+10
Case @"s" : tsize.f*1.01
Case @"S" : tsize.f*0.99
;Case @"r" : rot.f+6
End Select
End Select
FlushEvents
;If light Then glEnable_ #GL_LIGHTING: Else glDisable_ #GL_LIGHTING
;this example Show all what is possible with that 3dlib
gl_blit{0,xval,yval} ;simple blit a image
gl_light{ 0,320,yvallight,0,255,255,160} ;switch on a yellow spotlight
gl_color{255,150,150} ;tint texture red
;blit this image
gl_texcoord{0,tpos,0,128*tsize,128*tsize} ;for scroll the texture with m key
gl_blit{0,xval+128,yval} ;and blit
gl_light{0} ;now use the default light.
gl_blit{1,200,yval,zval,-1,0,0,rot} ;another image but rotatable -1 mean make that not transparent
;now blit a reflective object
gl_blit{7,xval-128,yval-128,zval,-1,rot+15,rot+15,0}
gl_texmode{3} ;now switch on the spherical mode for the reflect effect
gl_blit{8,xval-128,yval-128,zval,255,rot+15,rot+15,0} ;blit the reflection map
gl_light{ 0,220,yvallight,0,255,255,160} ;switch on a yellow spotlight for the font
gl_usefont {3,32,32,0.3} ;use picture 3 with 32*32 tile and scale the font by 0.5
gl_textcolor {220,220,220,200} ;we dont want the color of the bitmap
gl_print{"test",48,200} ;print 2 lines
gl_nprint{" 2. Part"} ;print 2 lines
gl_textcolor {0,200,255} ;change color again
gl_print{"This is a line scale to 0.4",65,230,0.4}
gl_light{0} ;default light
gl_color{160} ;make 2. ball a little darker only 1 color mean r g and b is set to 160
gl_scale{2.4,1.0,1.0} ;size the ball in x
gl_blit{1,300,yval,zval,trans,0,0,rot} ;make the ball transparent choose with g and t
gl_blit{4,300,100,0,-1,rot}
gl_color{255,200,0}
gl_scale{0.3,1,1}
gl_blit{4,320,250,zval,-1,-1,rot,-1} ;blit another sphere but diffrent color and size
gl_color{140,70,140} ;blit a reflective cone
gl_scale{0.5,1,1}
gl_blit{5,180,370,zval,-1,-1,rot,-1}
gl_scale{0.5,1,1}
gl_texmode{3}
gl_blit{6,180,370,zval,255,-1,rot,-1}
gl_texmode{3}
gl_blit{6,320,270,zval,150,-1,rot,-1} ;blit the transparency cone
gl_nprint{"Key r=Rotate "+Str$(rot),360,0}
gl_nprint{"m=Move Texture",360}
gl_nprint{"s=Size Texture",360}
gl_nprint{"Crsr = move",360}
gl_nprint{"q = z +",360}
gl_nprint{"a = z -",360}
gl_nprint{"Q = Light y +",360}
gl_nprint{"A = Light y -",360}
Delay_ 1
gl_show {} ;show the render and clear all realtime effects (it call gl_reset)
Until ev=#IDCMP_CLOSEWINDOW
End
CEND
-
Here is an old video (http://www.youtube.com/watch?v=E9uGOOv6uxA) from AmiTopiaTV which has a clip of me at the start playing Day of the Tentacle on my 8MB 68020 A1200 through WarpSDL (http://www.algonet.se/~chaozer/warpsdl.shtml). Just to show that an AGA-native SDL library can work, and that it's not too slow at all (this version of SCUMMVM runs far faster than any other, DOTT isn't playable even on my 030 unless I use WarpSCUMM).
[youtube]E9uGOOv6uxA[/youtube]
Video: http://www.youtube.com/watch?v=E9uGOOv6uxA
WarpSDL: http://www.algonet.se/~chaozer/warpsdl.shtml
-
I am not the author of netsurf SDL.Artur do a alot and great work on netsurf to add features that netsurf sdl version(in mains source do not have).In newest netsurf artur use agar GUI for GUI in some gadgets
http://libagar.org/
, i do not like the mix, i have told Artur, because i fear some hang problems due to message lost.I am not familar with that
But the sdl version can better update with new core, and if the standard core not run on amiga, i help Artur.
I think both of you are doing a good job but I wonder why you don´t adapt OS4 Reaction/ClassAct code as that would probably bring a notable improvement in usability and a good speed up in GUI too. In addition to that I would get rid of nasty ixemul and would use libc2 or libnix instead.
Uploading dependencies sources to Aminet would be helpful too I guess, perhaps that way somebody gets more interested in helping.
-
Is it a problem? There are 3D gfx cards for Amiga.
this give me the idea, to create for the SDL display a Warp3d context and implement for SDL hardware alpha blit function a function that paint a rectangle with texture in warp3d.
or look at other SDL implementation that use for this opengl.
so the Limit is not SDL.When a natami have a alpha blit function, natami can do too all blits lots faster with the blitter.and the CPU can init in the time the blitter work, the next alpha blit.so all work in same way as amiga blitter but with alpha channel
As i write before, SDL is not bad written, it have less calling overhead in blit functions as P96 and CGX.
Only on Amiga there is no hardware alpha support, and all need done in software.
On classic is 256 pixel texure limit, but the blit can split in diffrent calls automatic.
maybe i should ask natami devs, if i can get a natami to add SDl and hardware alpha support for natami. ;-)
But i am really lazy, maybe somebody else can do it.
Here is an old video (http://www.youtube.com/watch?v=E9uGOOv6uxA) from AmiTopiaTV which has a clip of me at the start playing Day of the Tentacle on my 8MB 68020 A1200 through WarpSDL (http://www.algonet.se/~chaozer/warpsdl.shtml). Just to show that an AGA-native SDL library can work, and that it's not too slow at all (this version of SCUMMVM runs far faster than any other, DOTT isn't playable even on my 030 unless I use WarpSCUMM).
[youtube]E9uGOOv6uxA[/youtube]
Video: http://www.youtube.com/watch?v=E9uGOOv6uxA
WarpSDL: http://www.algonet.se/~chaozer/warpsdl.shtml
the good thing on scumm is, that not the whole content of the display need redraw with 20 or more fps /sec(SDL can check to only redraw changed parts), and scumm games are very old.most games do not more as 320*240
Remember when the last lucas arts adventure with scummvm is release, and how much CPU power was here.
because when lucasarts scumm script system was program, PC are not fast.
but look when most SDL games are written.
SDL support alpha in Hardware, so if maybe the natami support a OS function that can blit alpha in hardware with blitter, then SDL can run lots faster.
SDL blit have less call overhead as P96.
I forget to write before
sdlquake and quake68k use only software render
-
Conclusion:
SDLquake is 37%-22% less speedy than clickboom's quake
Such a low spec machines every frame is important. Good result any way, I would ques that it is much more worse.
then try the test.let somebody else start sdlquake or quake68k in random order.
Now you need tell in 20 tries correct what version is faster.If you can tell this in 100% of the tries if the game run in 3 fps or 5 fps, then you are really good.
I know from my own tests, it doesnt matter, the game feel too slow.so you can see a classic is not able to do games in 640*480 16 bit
and quake is a good case test, remember quake have only 8 bit screen.When you use a 16 bit screen all go slower
@matthey
have you use for sdlquake the version i upload ?
the old version is lots slower.
Artur have use for all his games new SDl
-
I think both of you are doing a good job but I wonder why you don´t adapt OS4 Reaction/ClassAct code as that would probably bring a notable improvement in usability and a good speed up in GUI too. In addition to that I would get rid of nasty ixemul and would use libc2 or libnix instead.
Uploading dependencies sources to Aminet would be helpful too I guess, perhaps that way somebody gets more interested in helping.
Reaction GUI look very ugly, itix have done years ago a MUI interface for netsurf.thats the better choose, and we begin to port MOS MUI netsurf and it work a little.
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
So netsurf 68k use SDL, because SDL is mainted by a netsurf developer and all backend API changes he add in the SDL code.so amiga version can more easy keep upto date.
and when netsurf developers get not the idea to change backend api lots, then netsurf 68k have a MUI interface. ;-)
but netsurf dev change backend API, so netsurf 68k use SDL. ;-(
and only when java and doom work in netsurf, i have motivation to do more time spend on netsurf.
-
Reaction is not that ugly :) and it would be much easier task than start from scrats with MUI
Why not make better screen support? 8 bit screens? Amiga fonts? That should be possible wit SDL also. It would make lots of more useability to it and with Reaction/MUI gui it would feel like native amiga program.
-
Reaction is not that ugly :) and it would be much easier task than start from scrats with MUI
the reaction flat non shaded GUI elements from reaction i find more ugly as the current GUI elements in Netsurf
But when use zune MUI programs can look nicer.there is a MUI GUI for netsurf too here.
and OS4 reaction work diffrent as OS3 reaction.and OS3 reaction is a dead end.no enhance possible.MUI can enhance in zune.
also reaction can program really bad, class render is done in input device task.this mean if something fail to render in netsurf class, the whole amiga is dead, because when input device crash, no program can get mouse messages, or keyboard messages.
debuggers can not work to show correct errors.
all in all i see Reaction as a bad design.I do not like MUI too, because i want a GUI system that need not compile in the program code, and i want a GUI Editor, but at least MUI does not render in input device task.
Why not make better screen support? 8 bit screens? Amiga fonts? That should be possible wit SDL also. It would make lots of more useability to it and with Reaction/MUI gui it would feel like native amiga program.
the answer is simple. no sense see to spend alot work for this.and for something that make not fun, money is maybe a motivation.
Here can look on OS4, user pay for lots that is on other systems free(for example firefox and other bounties).But on 68k nobody do bounty, but whine when netsurf not run on a non gfx card system faster as on a fast PC.
I have the feeling some classic users want not pay any cent to upgrate their hardware.
But they want that developers work day and night for free, so that software that run on fast hardware run on their slow hardware too, so they need not put any cent to upgrade the amiga.
Instead the developer should spend work for free to strip the software down so it work on a Amiga.
what advantage should bring to use amiga fonts.I see only lots more work.
the fonts look ugly for inet pages.and noticable faster it not get.
I have written in older post, compare the netsurf load time with internal fonts(internal fonts work lots faster as amiga fonts) and truetype fonts.
If it really get faster with internal fonts, its possible to disable the antialiasing of the fonts.this cost most speed.
but as i told before, in real world pages, font render time is not very speed critical.most time is need for CSS layout, image decode and image show.
Software development cost lots time, so a good developer need to choose, time to add a feature and the usability of a code.
because time is short, then time need spend for features that bring a really good and usefull enhancement.
-
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?
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
Boynty is allways possible and I belive that many would take a part in it. BUT somebody who have needed knowledge should do it.
PS.
Clickboom's Quake outperforms SDLQuake and with 060 and AGA more than 6FPS, 14,58/FPS. I couldn't get SDLquake run AGA screen on my 060 machine.
-
I have the feeling some classic users want not pay any cent to upgrate their hardware.
True, but there are also people who want chipset+680x0. People who aren't interested in PPC+GFX card. I'm one of them. If I want more speed then I'll just use my peecee. If I want better graphics then I'll just use my peecee. And so on.
I'd rather spend money on other upgrades. Things such as more memory, mouse and keyboard controllers, network cards, etc. Even if a good Amiga GFX card only costs 5 bucks, I wouldn't be interested in using it and I would only buy it to make it available to people who are interested in it.
Chipset+680x0 can do more than is shown today, but it's just not so easy to get it done ;)
2. Disable requirement of true type fonts so that it would work with AGA
TrueType fonts can work with AGA. They can in fact work with C64 bitmaps if you wanted to.
-
Not without third party program and there is no benefit to use them with 8bit 640x512 screen
-
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?
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
Boynty is allways possible and I belive that many would take a part in it. BUT somebody who have needed knowledge should do it.
PS.
Clickboom's Quake outperforms SDLQuake and with 060 and AGA more than 6FPS, 14,58/FPS. I couldn't get SDLquake run AGA screen on my 060 machine.
you have forget to switch clickbooms AGA Version to 640*480
Or maybe when AGA is choose there is only a very limitet screen used.maybe 200*160 so that it is playable.
please make a screenshot, that show clickboom quake on aga
>True, but there are also people who want chipset+680x0. People who aren't interested in >PPC+GFX card. I'm one of them. If I want more speed then I'll just use my peecee. If I >want better graphics then I'll just use my peecee. And so on.
yeah and then you can use winuae faster and all this stuff on amiga OS too.
this help the programmer for 68k that they can faster develop.
But thats what i guess too. All that have no gfx card and slow amiga use mainly a PC and only want to test if a program can run.maybe they have fun to tell their friends look my amiga can run firefox.
And when the friend is gone the amiga guy use his PC to do that faster or in case of games in better image quality.
But its really frustrating for a amiga developer when guys have a fast PC, but want that the amiga developer should spend lots additional work, to get that on a real amiga working, so that the slow amiga guys have the feeling that they need no faster amiga and its possible with their old machine
Wy do the guys that want the software on real amiga working, not develop to get the softwarer working here on here loved system, or do a bounty ?.
Guys on slow amiga are not very active, big amiga only stuff as amiblitz, netsurf, hd-rec etc, all is done from developers with winaue.at least on 68k there develop some on good competite to PC Soft programs.On other AOS platform there are only Linux Ports, or some small and not comparable to PC Software projects
important for me and many more is use the software on amiga OS to have the look and feel of amiga OS window handling, desktop etc.I like dopus magellan and amiga window management (i configure click window to front with mid mouse key and back with shift mid key.)
On what hardware it run, doesnt matter for me.
this can see that most users use emulator or systems as vmware to run more OS on same Hardware together.
I need no extra Hardware when i know my PC can do it
-
All tests has made with same settings 320x200 8bit
SDLquake allows with aga only choose PAL/NTSC, and NTSC is choosed, otherwise I've choosed CGX screen 320x200 8bit
None of them has made with 640x480 because, that is simply not playable. 16bit screen drops FPS little, not much.
For me is important to have actual hardware, tune it to limits :) . I've 4 amigas. I've choosed to use only Zorro cards, because that was original 68k amiga expansion bus. I've also bouht harware new/old several times in this year.
-
I know from my own tests, it doesn't matter, the game feel too slow.so you can see a classic is not able to do games in 640*480 16 bit
20-25 fps is too slow for Quake? I think it's pretty playable. Putting the textures on the 3D gfx card avoids most of the gfx bus bottleneck. This can be used for bitmaps in 2D also as kas1e did with the Vague mags where the graphics are fast and crisp. SDL could do this transparently for 2D also so users with a 3D card get a fast and pretty display while users without get slow and ugly :P. There is plenty more room for speedups in W3D too. I would be more motivated to optimize if there were more programs using W3D.
@matthey
have you use for sdlquake the version i upload ?
the old version is lots slower.
Artur have use for all his games new SDl
Yes. I used the version of SDLQuake you linked. It didn't seem to use StormMesa->Warp3D even when I selected 640x480 16 bit PC. It was slow and ugly (like 8 bit). Shouldn't it use StormMesa->Warp3D automatically if the version of SDL linked is new enough, SDL 3D is used, and the screen mode supports hardware acceleration?
Also, Why hasn't the SDL library as an Amiga shared library caught on? It doesn't make much difference for games but there is a huge advantage to share code when it's used in utilities (e.g. a web browser) as a gui.
-
@utri007
>SDLquake allows with aga only choose PAL/NTSC, and NTSC is choosed, otherwise I've >choosed CGX screen 320x200 8bit
i dont understand you, sdlquake work not with AGA and default in 640*480.
if you mean clickboom quake and AGA ntsc is 320*200 and pal setting is 320*240.
when you choose ntsc setting, the width is not really 320.it is 266 Pixels.so there is some black gap on side.
its because quake is a 4:3 aspect ratio Game.this mean 200/3*4=266 width.
so its of course faster as in PAL in NTSC.
but you not find any SDL game that run in 266*200 Pixels.
266*200 53200 Pixels the computer need calculate and transfer to GFX Card.
320*240 =76800 Pixels.
640*480 are 307200 Pixels.
this mean 307200/53200 = 5.7
So a computer that play the game at same framerate at 640*480 need 5.7* faster as a computer that play the game at 266*200
quake is because of opengl able to run on all resolution because it use 3d and scaling.but you see quake graphic is more ugly as a amiga game for 320*200
2D games are written for a fixed resolution, so you have lots work to do all graphic for lower resolution.
>For me is important to have actual hardware, tune it to limits
then tell me a reason wy somebody should spend alot of time to get software on your slow amigas working ?
another solution is, you learn programming and spend the time to do it yourself.wy do you not do this.It is not so hard.only you need lots time.if you have no time for this, wy other should have time for this ?
I like too when all this modern software can run on a A500, but i know its just impossible to run it in same quality as on a faster system.Time is short, life is short, there can lots more and more intresting do, as make software running on a slow system
In the early amiga days no computer was able to run games as good amiga can do.so all must live with the 320*240 quality.but when today can play the same game in 640*480 16 bit or more, wy should play it in 266*200 in AGA ?
20-25 fps is too slow for Quake? I think it's pretty playable. Putting the textures on the 3D gfx card avoids most of the gfx bus bottleneck. This can
be used for bitmaps in 2D also as kas1e did with the Vague mags where the graphics are fast and crisp. SDL could do this transparently for 2D also so users with a 3D card get a fast and pretty display while users without get slow and ugly :P. There is plenty more room for speedups in W3D too. I would be more motivated to optimize if there were more programs using W3D.
Yes. I used the version of SDLQuake you linked. It didn't seem to use StormMesa->Warp3D even when I selected 640x480 16 bit PC. It was slow and ugly (like 8 bit). Shouldn't it use StormMesa->Warp3D automatically if the version of SDL linked is new enough, SDL 3D is used, and the screen mode supports hardware acceleration?
Also, Why hasn't the SDL library as an Amiga shared library caught on? It doesn't make much difference for games but there is a huge advantage to share code when it's used in utilities (e.g. a web browser) as a gui.
sdlquake use no 3D.only software render.
Normaly need link with a libsdl that open not stormesa when a program not use SDL GL.but i have compile the version only for my tests.see the date, its some years old.
I only want see if SDL is fast now.and it is fast, speed is near same as quake68k.how fast clickboom quake is and if it have some optimized 68k asm routines i dont know.sdlquake have of course no asm code.
If you have time and knowledge to do a amiga shared library for sdl you are welcome to do that.Problem is SDL have more than 300 calls to opengl.thats alot of work
the old shared SDL do not support opengl.so there need new lib files and stubs create for GCC.
sdl is not big, only around 70 kb.that the files are larger is because i release all libs with debugging symbols.if somebody really want save some kb, he can strip the exe with the strip command.
>20-25 fps is too slow for Quake? I think it's pretty playable.
this i think too good playble.
But i dont think if you notice a diffrence when you not measure it, when quake run a few frames faster.for example 24 instead of 21 fps.
-
On archive that you linked has a GUI / Launchtool for SDLQuake, I used it and it worked. I woun't belive that it could accidentally launch any other Quake.exe.
Or is there already one? How have you configured it? I need to check it tomorrow, when I get back to home.
It must be SDL quake, it requires assing TMP and it is needed no matter do I use gui or not.
-
"I only want see if SDL is fast now.and it is fast, speed is near same as quake68k.how fast clickboom quake is and if it have some optimized 68k asm routines i dont know.sdlquake have of course no asm code."
As I told you previously, there are little functions of SDL involved in SDL Quake:
-Opening Screen
-Locking Bitmap to copy raw data or copying the raw data directly without ANY conversion involved.
-Unlocking Bitmap in case you locked it.
-Switwing buffers
-Closing Screen
And no Blit or RGB conversion functions so comparing CGX with SDL using Quake is both absurd and useless.
In order to compare CGX and SDL performance you would need to compare RGB conversion, blitting, blitting with a mask... but not performing a plain 8bit pixel copy to a 8bit screen! You won´t get important differencies, the only ones you may find would be that ClickBoom Quake may be configured to write directly to a bitmap resulting in higher performance if you have good bandwitch to gfx ram and SDLQuake will probably perform a copy of the pixels from the rendering buffer to the screen bitmap but that doesn´t require a single conversion so trying to compare SDL&CGX performance using Quake is ridiculous.
If you are so interested in comparing CGX&SDL performance it´s not complex to write a small app that performs operations colour conversion, blitting with different sizes, blitting with mask... and then compare the results.
But please stop trying to reach conclusions about CGX&SDL performance using Quake because it´s the worst game you could use to compare.
Following your logic I could use an AROS native version of Quake, set it to write directly to the screen buffer and claim that CGX blitting and masking functions are as efficient and feature rich as DirectX hardware accelerated ones because I would get similar performance as Windows version: just because Quake is the wrong test!
-
>If you are so interested in comparing CGX&SDL performance it´s not complex to write a >small app that performs operations colour conversion, blitting with different sizes, blitting >with mask... and then compare the results.
color conversions are not need in SDL Blit.SDL games should convert all loaded image to screen format first.
if((temp = SDL_LoadBMP(filename.c_str())) == NULL)
object = SDL_DisplayFormat(temp);
SDL_FreeSurface(temp);
SDL_DisplayFormat do the Job.
so a blit is only a memory copy.and sdl 1 pixel alpha blit(mask) software func is lots faster as P96 or CGX can do.read the theory
http://old.nabble.com/RLE-Compression-td22985131.html
P96 and CGX can not do this mask blits in Hardware on amiga GFX Cards on cgx screens.all is done in software with the CPU.i see that with debug the functions.
P96 speed offer no test for mask blit.they know wy, because its realy slow on amiga.or do you know a amiga speed test that test mask blits.here you can see if this is slower as normal blits it work not in Hardware
more than 1 bit alpha(mask blitting) support does CGX or P96 not support.but this is much more slow.today all SDL games need more than simple mask blitting.
because blits are simple memcopy operations, all depend from memspeed and gfx card speed.thats the weak point of the amiga.also that amiga GFX Cards have not much RAM
>If you are so interested in comparing CGX&SDL performance it´s not complex to write a >small app that performs operations colour conversion, blitting with different sizes, blitting >with mask... and then compare the results.
I know SDL is faster with RLE, but when i spend time to show that, there are for shure guys that wont believe the Fact and say the benchmark is wrong written.
So the best thing a developer can do, if amiga users dont want SDL games because they call it as slow, do nothing.
maybe this guys learn a little program and see in a own written benchmark, that SDL is not slow.
>But please stop trying to reach conclusions about CGX&SDL performance using Quake >because it´s the worst game you could use to compare.
Yes quake is not best, but i do not know a better game that is here for sdl and amiga native.
so the speed brake is not SDL, its the game design, use of alpha channel etc.too much data for a classic.the 68k need wait lots for blitting.
On archive that you linked has a GUI / Launchtool for SDLQuake, I used it and it worked. I woun't belive that it could accidentally launch any other Quake.exe.
Or is there already one? How have you configured it? I need to check it tomorrow, when I get back to home.
It must be SDL quake, it requires assing TMP and it is needed no matter do I use gui or not.
I linked the full source of sdlquake.I see no quake launcher file in this.what name it have ?
I look in the source, there is a option -winwidth. when choose -winwidth 320 200 it use a 640* window and run in window mode.this is slower as fullscreen
when quake really run in 320*200 there should the display not wider as the status bar at bottom.
quake defaults in source are 640*480
// The original defaults
//#define BASEWIDTH 320
//#define BASEHEIGHT 200
// Much better for high resolution displays
#define BASEWIDTH (320*2)
#define BASEHEIGHT (200*2)
......
vid.width = BASEWIDTH;
vid.height = BASEHEIGHT;
vid.maxwarpwidth = WARP_WIDTH;
vid.maxwarpheight = WARP_HEIGHT;
if ((pnum=COM_CheckParm("-winsize")))
{
if (pnum >= com_argc-2)
Sys_Error("VID: -winsize \n");
vid.width = Q_atoi(com_argv[pnum+1]);
vid.height = Q_atoi(com_argv[pnum+2]);
if (!vid.width || !vid.height)
Sys_Error("VID: Bad window width/height\n");
}
-
This one:
http://www.zshare.net/download/93491293cd6725de/
name is Quake, hmmm could it be actually quake,exe with gui? I thought it was laucnher? Size is 468kb
-
This one:
name is Quake, hmmm could it be actually quake,exe with gui? I thought it was laucnher? Size is 468kb
I test the quake file, oh, sorry, this was the native quake68k from Frank Wille.you need start sdl_quake.exe(which is compile with gcc 4.3) .or you can try sdl_quake3.4.exe which is compile with GCC 3.4
seem i move this quake file to dir for more easy test in my sdl_quake source.normaly need remove the archive, but i dont save the link to remove the archive.
I have send a report hope zshare remove this archive soon.
-
OK :D now we know that Franks's quake is not optimized as Clickbooms's quake is, but at least it has a nice gui
-
OK :D now we know that Franks's quake is not optimized as Clickbooms's quake is, but at least it has a nice gui
please look if the image quality is really the same.not that clickboom quake do reduce the calc from 320 to 160 and do pixel doubling to be faster.
or can you make a screenshot of both and upload them ?
I guess quake68k is only on AGA slow.clickboom maybe have better optimized chunky to planar code
sdl_quake was not much slower as clickboom quake on gfx card, see test from matthey.
and sdlquake on my system was too not much slower as quake68k.
this look more, that slowdown is only in AGA.
-
I can't run tests now, need to wait tomorrow. I feel hard to belive that clickboom's quake would reduce screen size. Double buffering is not eneabled by default, if I want to use it, I need to turn it on.
Edit:. Sorry, yes double sized pixels, same thing, if I want to use them I need to turn that feature on.
-
sdl_quake was not much slower as clickboom quake on gfx card, see test from matthey.
and sdlquake on my system was too not much slower as quake68k.
Actually, my test was with Frank Wille's version of Quake also. I tried the SDLQuake once but figured Frank's Launcher was a Launcher for SDL_Quake that allowed options. It looks like SDL_Quake uses 640x480 by default. It may be 16 bit as it looks better than Frank's Quake in 8 bit. Here are the results I get with defaults...
SDL_Quake 3.3fps 3.4fps
SDL_Quake_3.4 3.8fps 4fps
This is with timedemo demo1 like my other results. The second number is with MuRedox that avoids trapped instructions. Notice that the GCC 3.4 compiled version is faster despite possibly using more trapped instructions.
-
Thanks matthey :) it is actually nice to see that somebody else is making same mistakes than me :D
But it seems that SDLQuake is doing same results, than Frank's quake port with hires screemodes.
BUT as have been said, this is quite useless test. Is it so that you have used Frank's engine with your SDL port? So you know how small SDL role is with this test.
-
Thanks matthey :) it is actually nice to see that somebody else is making same mistakes than me :D
But it seems that SDLQuake is doing same results, than Frank's quake port with hires screemodes.
BUT as have been said, this is quite useless test. Is it so that you have used Frank's engine with your SDL port? So you know how small SDL role is with this test.
If you believe what a user tell that seem have not done any test on SDL and CGX or P96 its up to you.
If some of the "cgx/p96 is faster as SDL" experts can tell me exact how i need write the testprogram i can do so.
But i never will spend time to write a own testprogram, because i am 100% sure, the "experts" bring the excuse when show that SDL is faster as P96/cgx that i have written the program wrong.
The performance of a game depend on the speed of mask blitting, because all game objects are not simple rectangle with no transparent.only the large background can blit without mask.
And mask blitting is on P96 not very fast, and is done with the CPU.when you have the bitmap in gfxcard, then the background is multiple overwritten. bad for this extreme slow GFX Card Bus of amiga that is used on mediator and A1200.
SDL is the best and fastest Game Engine for C on amiga, i have at least done enough tests to verify that.
My first idea was too, just wrap the the SDl blitfunctions to P96 Blit functions.but it was slow as hell then, mostly on mask blit.
i use for test openredalert, that do many small blits of the small soldierm cars etc, with mask blit.
and use of a real alpha channel is not possible with CGX/P96, no hardware and CPU support
real alpha calc is extrem slow to do with CPU.o games that use real alpha are more unusable on a classic.
>BUT as have been said, this is quite useless test. Is it so that you have used Frank's engine with your SDL port?
sdl_quake is only a quick compile of Linux Version on amiga, no changes.sound is done too with sdl.
-
@bernd
Why not use Warp3D on Amiga's with 3D hardware for 2D SDL? Use textures for 2D bitmaps and then there is MUCH more control of what is "blitted". Once the textures are on the card and if there is enough memory for all of them, then the gfx are as fast as the 3D card instead of being limited by the gfx bus or the 68k CPU. The Vague magazine works great in 2D using Warp3D. It's fast and flawless. kas1e has given tips to using Warp3D like this. I bet he would even let you see the source.
-
@bernd
Why not use Warp3D on Amiga's with 3D hardware for 2D SDL? Use textures for 2D bitmaps and then there is MUCH more control of what is "blitted". Once the textures are on the card and if there is enough memory for all of them, then the gfx are as fast as the 3D card instead of being limited by the gfx bus or the 68k CPU. The Vague magazine works great in 2D using Warp3D. It's fast and flawless. kas1e has given tips to using Warp3D like this. I bet he would even let you see the source.
I have suggest that earlier in thet thread, and i tell, i have no to time to do it with warp3d.i never use warp3d and i want not learn it.its obsolete.maybe somebody can do a poll how many amiga users with a Voodoo 3 card are here with enough memory and how many of them are intresting on SDL games.
I guess not very much.Problem is also that new SDL games use mostly more than 8 megabyte that have voodoo 3 as texture memory.
its also not clear what problems happen with warp3d.Some programs want direct access to the bitmap and poke in some data.
-
I have suggest that earlier in thet thread, and i tell, i have no to time to do it with warp3d.i never use warp3d and i want not learn it.its obsolete.maybe somebody can do a poll how many amiga users with a Voodoo 3 card are here with enough memory and how many of them are intresting on SDL games.
Warp3D is easy to use and logical but I hear you about becoming obsolete. I expect that Warp3D.library will use Gallium at some point instead of talking to the hardware directly. Using Gallium directly would probably make better sense when it's ready in AROS. Classic users aren't going to use AROS until it's better optimized though. It's always the chicken and the egg problem on the Amiga isn't it? I think some Natami users will use a PCI gfx card also until the 3D engine in Natami is ready and maybe afterward. I expect the gfx card will be faster but less flexible. There is also talk Karlos releasing a 68k version of his Warp3D Radeon driver over on Amigaworld.net. My point is that the user base of 3D gfx cards on the Amiga should grow. I can see your hesitation to develop for an unknown future direction though. There's no big hurry anyway.
I guess not very much.Problem is also that new SDL games use mostly more than 8 megabyte that have voodoo 3 as texture memory.
The Voodoo 3 has 16MB and Voodoo 4-5 32MB usable. This actually goes pretty far with 2D bitmaps as there are no mipmaps necessary. The Voodoo 3 256x256 texture limit is a pain though. I think I can get the Voodoo 4-5 Warp3D library to do large textures but I'm waiting until the Voodoo 3 driver is more complete and optimized before making a Voodoo 4-5 (Napalm driver). I'm currently working on ADis at the moment though.
its also not clear what problems happen with warp3d. Some programs want direct access to the bitmap and poke in some data.
Poking the data is a bad idea. Warp3D takes the bitmap/texture in the format given and converts and creates a texture on the gfx card in a native and efficient format to use. The original data can be poked if Warp3D is made aware of it but then the data has to be converted and copied through the slow gfx bus again. It's probably not a good idea to try and poke the texture directly in memory even with the hardware locked. I don't think Warp3D provides any interface for that either.
-
Unless you are going to extend Warp3D API it is probably too painful to use with SDL for 2D acceleration. SDL allows locking HW sufraces (Amiga bitmaps allocated from VMEM) and let programs directly manipulate HW bitmaps.
VMEM probably is not problem on old Amigas. Most users there are using 1024x768 low-res.
-
Poking the data is a bad idea. Warp3D takes the bitmap/texture in the format given and converts and creates a texture on the gfx card in a native and efficient format to use. The original data can be poked if Warp3D is made aware of it but then the data has to be converted and copied through the slow gfx bus again. It's probably not a good idea to try and poke the texture directly in memory even with the hardware locked. I don't think Warp3D provides any interface for that either.
there are many programs that poke data direct.for example to draw dots of a starfield, or lines or arcs a lock is call for SDL surface and it use the surface address to put data into.
I remember from winuae native warp3d, that freespace 68k too poke in graphics memory(the cockpit and video).if you can debug warp3d function calls, maybe you can look how freespace do that.
but how this must program in warp3d i dont know.there need somewhere a buffer flush that all polygons are draw and then the programm do a lock of the buffer with CGX function.
-
Unless you are going to extend Warp3D API it is probably too painful to use with SDL for 2D acceleration. SDL allows locking HW sufraces (Amiga bitmaps allocated from VMEM) and let programs directly manipulate HW bitmaps.
True, Warp3D currently has no API for this.
I remember from winuae native warp3d, that freespace 68k too poke in graphics memory(the cockpit and video).if you can debug warp3d function calls, maybe you can look how freespace do that.
but how this must program in warp3d i dont know.there need somewhere a buffer flush that all polygons are draw and then the program do a lock of the buffer with CGX function.
It would probably work to do something like this...
W3D_SetState(context, W3D_AUTOTEXMANAGEMENT, W3D_DISABLE);
texture = W3D_AllocTexObj(context, &error, tags);
W3D_LockHardware();
if (texture)
poke (texture->texdest); // texture location on card defined in Warp3D.h
W3D_UnLockLockHardware();
This is a violation of the API but it would probably work with most gfx cards. There may be gfx card specific reasons why this would not work though. It would be much safer and more flexible but slower to alter the source texture/bitmap and call W3D_UpdateTexImage() to convert and copy it to the gfx card as a texture. Converting could be avoided if all the texture/bitmap data was converted to the display format. This should still be advantageous if most textures/bitmaps don't change.
-
True, Warp3D currently has no API for this.
It would probably work to do something like this...
W3D_SetState(context, W3D_AUTOTEXMANAGEMENT, W3D_DISABLE);
texture = W3D_AllocTexObj(context, &error, tags);
W3D_LockHardware();
if (texture)
poke (texture->texdest); // texture location on card defined in Warp3D.h
W3D_UnLockLockHardware();
This is a violation of the API but it would probably work with most gfx cards. There may be gfx card specific reasons why this would not work though. It would be much safer and more flexible but slower to alter the source texture/bitmap and call W3D_UpdateTexImage() to convert and copy it to the gfx card as a texture. Converting could be avoided if all the texture/bitmap data was converted to the display format. This should still be advantageous if most textures/bitmaps don't change.
I guess they do not alloc a texture and do just render, after 3d is draw to the P96 screen.
thats the easiest way.
I see a simple program that too have problems on winuae quarktex.its
the warp3 test demo of warp3d dev .the text is not see.
Here can see, in source warptest.c in DrawWall func.they just put text in the window rastport.I test with wazp3d the software warp3d. strange is the text is draw after
W3D_UnlockHardware
Hardware and always draw below 2 triangles for 3d quadrat(zoom full with cursor up).but the 3d is draw before, so text should normaly always on top.what happen with your voodoo 3 ?
....
W3D_UnLockHardware(context);
SetAPen(window->RPort, 249);
RectFill(window->RPort, 638,0,639,1);
// If the user flipped the bflag on, draw the coordinates at the
// polygon vertices
if (bflag) {
SetAPen(window->RPort, 255);
for (i=0; i<4; i++) {
#ifndef __STORM__
Move(window->RPort,(long)TempSquare[i].x, (long)TempSquare[i].y+(1-bufnum)*480);
sprintf(buffer, "%3.2f,%3.2f", TempSquare[i].z, TempSquare[i].iz);
Text(window->RPort, buffer, strlen(buffer));
#else /* compiler bug workaround */
float temp, temp2;
temp = TempSquare[i].iz;
temp2 = TempSquare[i].z;
Move(window->RPort,(long)TempSquare[i].x, (long)TempSquare[i].y+(1-bufnum)*480);
sprintf(buffer, "%3.2f,%3.2f", temp2, temp);
Text(window->RPort, buffer, strlen(buffer));
#endif
}
but luckily opengl programs are not written in such a way, that it access data in screen direct, so its not big problem.but for SDL need direct access, either before or after render.
and maybe warp3d work, when call warp3d unlockhardware every time a sdl program call a SDL lock.should not too slow, becsause SDl programs call only every frame a look
I think use for MOS warp3d in SDl is too usefull, because the efica CPU is slow, and so efica can play fast SDL 2D games too
-
I guess they do not alloc a texture and do just render, after 3d is draw to the P96 screen. Thats the easiest way.
That is basically what is done if no conversion of texture format is necessary. A pointer to the texture data and a tag for the data format is passed to W3D_AllocTexObj(). That texture data is copied to the gfx card as needed if no conversion is necessary. A native version is created by converting first if needed. Most Warp3D programs use W3D_AUTOTEXMANAGEMENT which swaps textures in and out as needed but it can be turned off allowing the programmer to control when textures are put in or removed from gfx mem.
I see a simple program that too have problems on winuae quarktex.its
the warp3 test demo of warp3d dev .the text is not see.
Here can see, in source warptest.c in DrawWall func.they just put text in the window rastport.I test with wazp3d the software warp3d. strange is the text is draw after
W3D_UnlockHardware
Hardware and always draw below 2 triangles for 3d quadrat(zoom full with cursor up).but the 3d is draw before, so text should normally always on top.what happen with your voodoo 3 ?
The coordinates are drawn correctly here. I believe it's proper to draw after W3D_UnLockHardware(). I believe W3D_LockHardware() waits for the gfx card to be idle and then blocks (Forbid or Disable) any other programs from using the gfx card. The debugger won't even work after a W3D_LockHardware(). Holding this lock for too long will likely cause the machine to freeze.
but luckily opengl programs are not written in such a way, that it access data in screen direct, so its not big problem.but for SDL need direct access, either before or after render.
and maybe warp3d work, when call warp3d unlockhardware every time a sdl program call a SDL lock.should not too slow, because SDl programs call only every frame a look
It's safe to change the original texture data and inform W3D of the update. It's probably NOT safe to change the texture in gfx memory. It's probably possible if carefully done but it violates the W3D API and may not work on all versions of W3D or all gfx hardware. Doesn't SDL go through OpenGL or DirectX to access the gfx hardware?
-
That is basically what is done if no conversion of texture format is necessary. A pointer to the texture data and a tag for the data format is passed to W3D_AllocTexObj(). That texture data is copied to the gfx card as needed if no conversion is necessary. A native version is created by converting first if needed. Most Warp3D programs use W3D_AUTOTEXMANAGEMENT which swaps textures in and out as needed but it can be turned off allowing the programmer to control when textures are put in or removed from gfx mem.
The coordinates are drawn correctly here. I believe it's proper to draw after W3D_UnLockHardware(). I believe W3D_LockHardware() waits for the gfx card to be idle and then blocks (Forbid or Disable) any other programs from using the gfx card. The debugger won't even work after a W3D_LockHardware(). Holding this lock for too long will likely cause the machine to freeze.
It's safe to change the original texture data and inform W3D of the update. It's probably NOT safe to change the texture in gfx memory. It's probably possible if carefully done but it violates the W3D API and may not work on all versions of W3D or all gfx hardware. Doesn't SDL go through OpenGL or DirectX to access the gfx hardware?
you seem not understand the example program, the program do not modify a texture data, it do write text in same way as any Amiga program do.Text is a AOS graphics library function, and no warp3d specific
Text(window->RPort, buffer, strlen(buffer));
when you look on init you see that window variabale is the result of a AOS openwindow Call.
struct Window *window;
......
// Open window
// While this is not strictly nessessary, we use it because
// we want to get IDCMP messages. You can also use the screen's
// bitmap to render
window = OpenWindowTags(NULL,
WA_CustomScreen, (ULONG)screen,
WA_Activate, TRUE,
WA_Width, screen->Width,
WA_Height, screen->Height,
WA_Left, 0,
WA_Top, 0,
WA_Title, NULL,
WA_CloseGadget, FALSE,
WA_Backdrop, TRUE,
WA_Borderless, TRUE,
WA_IDCMP, IDCMP_CLOSEWINDOW|IDCMP_VANILLAKEY|IDCMP_RAWKEY|IDCMP_MOUSEBUTTONS|IDCMP_MOUSEMOVE|IDCMP_DELTAMOVE,
WA_Flags, WFLG_REPORTMOUSE|WFLG_RMBTRAP,
TAG_DONE);
-
you seem not understand the example program, the program do not modify a texture data, it do write text in same way as any Amiga program do.Text is a AOS graphics library function, and no warp3d specific
Text(window->RPort, buffer, strlen(buffer));
when you look on init you see that window variable is the result of a AOS openwindow Call.
struct Window *window;
That looks fine to me. There isn't any W3D screen or window calls. Bitmaps are the target of W3D function calls. Intuition screens and windows are supported. This allows function calls like graphics.library/Text() to be used where there is a RastPort pointing to the same bitmap.
-
That looks fine to me. There isn't any W3D screen or window calls. Bitmaps are the target of W3D function calls. Intuition screens and windows are supported. This allows function calls like graphics.library/Text() to be used where there is a RastPort pointing to the same bitmap.
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.
-
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.
-
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.
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;
}
.......
-
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 (http://www.netsurf-browser.org).
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!
-
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.
-
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.
-
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.
-
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 :(
-
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.
-
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
-
@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...
-
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.
-
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.
-
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 :)
(http://www.amiga.org/gallery/images/5682/2_curse_of_monkey.jpg)
-
Thanks :D
-
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 ?
-
@NovaCoder
Good job! :-)
-
Sorry for the off topic-ness, but:
@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 ?
Yep it's down to gcc I'm afraid, I can only link it so many engines before the compiler has a sulk and spits the dummy. There's not much point supporting SVGA games for the AGA version anyway because 640x480x256 is too slow in AGA and I only support Curse of Monkey Island in AGA. For the RTG version I will also add support for Broken Sword 2 and maybe Broken Sword 1 as well :)
-
Yep it's down to gcc I'm afraid, I can only link it so many engines before the compiler has a sulk and spits the dummy. There's not much point supporting SVGA games for the AGA version anyway because 640x480x256 is too slow in AGA and I only support Curse of Monkey Island in AGA. For the RTG version I will also add support for Broken Sword 2 and maybe Broken Sword 1 as well :)
Are you using MMU to avoid performing c2p and redrawing the non updated parts? IIRC ADoom had some code to do that and it could be quite helpful on machines with MMU. Scrolling would be slow but other scenes would be fast. Perhaps you could add some optional frameskipping in games that use 640x480 (and with MMU onlyenable it on scenes with many changes -let's say more than 50%-, I guess that looking at MMU code from ADoom it would be possible to add a counter of modified chunks and if more than half of chunks have been modified activate frameskipping).
There was a video driver for Shapeshifter called AGABoost that worked without MMU and only drawed modified parts although MMU support would be great anyway.
-
POint & Click adventure 640x480 should be playable with AGA
-
Are you using MMU to avoid performing c2p and redrawing the non updated parts? IIRC ADoom had some code to do that and it could be quite helpful on machines with MMU. Scrolling would be slow but other scenes would be fast. Perhaps you could add some optional frameskipping in games that use 640x480 (and with MMU onlyenable it on scenes with many changes -let's say more than 50%-, I guess that looking at MMU code from ADoom it would be possible to add a counter of modified chunks and if more than half of chunks have been modified activate frameskipping).
IIRC ADoom didnt use MMU to avoid drawing non-updated parts but instead marked frame buffer as non-cacheable. Could be I remember wrong but ADoom indeed ran faster on certain setups.
-
IIRC ADoom didnt use MMU to avoid drawing non-updated parts but instead marked frame buffer as non-cacheable. Could be I remember wrong but ADoom indeed ran faster on certain setups.
You may be right... although ADoom uses a comparison buffer so I guess it does something like I described. To get some advantage of the MMU it probably creates various MMU pages pointing to parts of the chunkybuffer and marked as read only and when an "Exception" is raised in the memory area of that page, unmark it as "read only ram" and execute the instruction that caused the exception. Then at the end of the writes check out the small table of "zone-flags" and perform the c2p of that parts of the display. I guess it works in 4KB slices (it would be nicer with smaller chunks).
Looking at some Mac Emu driver could be handy. This one is done by the same author of the c2p (it uses a delta buffer so I'm fairly sure it works as I thought ADoom worked):
http://aminet.net/package/misc/emu/TurboEVD-src