|
|---|
Team Chaos Leader
USA
| | (Moderator)
Posts 2094
10 Nov 2011 22:38
| Team Chaos Leader wrote:
|
p.s. If you are going to trick Phil into coding a gfx routine, then please trick him into coding a PNG loading routine in asm. You could make one in C if you like. A PNG loading routine is something that all Amiga coders could make use of. I have a personal need of such a routine as do all gfx coders.
|
Heheh. Who are you trying to trick, really ? You know I already have written one, don't you ?
|
I could not remember. My brain is way overloaded :(
I knew for sure u had done a jpeg loader years ago.Team Chaos Leader wrote:
|
> There is already PNGLIB from years ago, sitting on Aminet, written in C. I win. :)
|
Phil G. wrote:
|
No, you lose. This code is damned slow and unusable :p
|
Thanx for the warning. I will try to stay away from it. All I remember from it was that it can somehow feed u 1 line at a time so its possible to clip it as it loads. Team Chaos Leader wrote:
|
But it does not clip the incoming bitmap to the size of the supplied bitmap like iff.library does. You could prob tack that on in 30 mins then it would be 100% usable by all us lowly gamecoders.
|
Phil G. wrote:
|
Just load your bitmap, then use a generic clipper afterwards. Problem solved ;-)
|
I guess so... I mean it can work and is quick and ez 2 c0de. But it does go against my coding philosophy, which is to avoid doing AllocMem() in the middle of the program. This fragments memory and dooms the program to eventual failure. Also since ppl will sometimes be feeding in giant 4000x3000 .jpgs and .pngs the allocmem required is a HUGE 48 MB and will fail very quickly, maybe even on the very first try. With ClipAsYouLoad(tm) Technology any size image will load every time into my preallocated 1280x1024 bitmap. Anyway I may use your technique.... I am just trying to explain why I am not all that enthusiastic about it. I am always perpetually low on memory and I need to avoid doing huge temp "AllocVec()" or as Thor would say: "malloc()" :)
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3974
10 Nov 2011 22:52
| I am not even a very good programmer and i know to stay away from Malloc() unless there is no otherway out.
| |
Thomas Richter
Germany
| | (MX-Board Owner)
Posts 1425
12 Nov 2011 20:29
| Marcel Verdaasdonk wrote:
|
I am not even a very good programmer and i know to stay away from Malloc() unless there is no otherway out.
|
Yes, memory management on the Amiga is... challenging. For AllocMem(), you don't have an operating system that cleans up behind you if you forget to release memory, unlike on *ix* or win32. On the other hand, stack space is also limited, having typically 4K available for your disposal...Greetings,
Thomas
| |
Team Chaos Leader
USA
| | (Moderator)
Posts 2094
13 Nov 2011 02:45
| I have 200K stackspace at my disposal. Saves me a zillion AllocMem() FreeMem()
| |
Thomas Richter
Germany
| | (MX-Board Owner)
Posts 1425
13 Nov 2011 10:13
| Team Chaos Leader wrote:
|
I have 200K stackspace at my disposal. Saves me a zillion AllocMem() FreeMem()
|
Well, but you either need to tell the user to increase the stack space, or swap the stack yourself (then again requiring AllocMem()), or use the new $Stack "cookie" the 3.9 shell introduced. Problem is, in most cases you waste memory because only a fraction of the stack is used, or you run out of bounds without any further check and then crash.*ix* auto-extends the stack, i.e. it silently allocates memory for you if you need more stack space, much easier. Stack is neither always the solution - if your algorithm require dynamic objects, you need to decouple the function call stack from the object storage necessarily, and then you need to allocate memory in one way or another.
| |
Phil "meynaf" G.
France
| | (Natami Team)
Posts 393
14 Nov 2011 08:15
| Team Chaos Leader wrote:
|
All I remember from it was that it can somehow feed u 1 line at a time so its possible to clip it as it loads.
|
If you don't want to allocmem for the whole image, but just receive it line by line, this is exactly what my code does (however, depending on format, it won't give you the lines in any particular order).
That said, it may be better to choose ONE image format and stick to it ; there are conversion tools for when you receive data in other formats.Team Chaos Leader wrote:
|
I am always perpetually low on memory and I need to avoid doing huge temp "AllocVec()" or as Thor would say: "malloc()" :)
|
Ah, yes, good AllocVec(). I have wrapper code to call it (among many other things), which automatically releases memory upon exit :D
I also have code to StackSwap() easily, too. Even though my own code is more than satisfied with 4k (usually 1k should suffice), my ReSource of HOMM2 requires a lot more (64k IIRC).
| |
Team Chaos Leader
USA
| | (Moderator)
Posts 2094
14 Nov 2011 08:53
|
Team Chaos Leader wrote:
|
All I remember from it was that it can somehow feed u 1 line at a time so its possible to clip it as it loads.
|
Phil "meynaf" G. wrote:
|
If you don't want to allocmem for the whole image, but just receive it line by line, this is exactly what my code does (however, depending on format, it won't give you the lines in any particular order).
That said, it may be better to choose ONE image format and stick to it ; there are conversion tools for when you receive data in other formats.
|
All I know is that, on general principle the game should accept .jpg and .png gfx because the concept of the game is that it is a wiki that any joe blow can modify.The official format of Team Chaos 16M color gfx is PNG but we do have a lot of old JPG gfx from the 1990s that various ppl sent in. I could simply use your code "as is" and that would still be better than using a datatype, right? Then if the temp image load is too big for the available ram I just put up an Alert "?Out of Memory Error in Phil's Image Loader. Please buy more ram, use a smaller image, or use TLSFMem to keep your ram from being so fraggled. KTHANXL8RBYE :)" As long as the instructions say "Game requires Natami or UAE with 512MB ram" Everything should be ok.
| |
Phil "meynaf" G.
France
| | (Natami Team)
Posts 393
14 Nov 2011 09:26
| My code has error handler calling some kind of "abort" primitive, with an error message. Standard behaviour from me is just to abruptly quit application with that message - perhaps this is not what you want for your game :) Also I emit a lot of warnings for images with useless chunks, extraneous data, bad encoding... but these can be ignored. Well, you know my mail already, so I can give you all the details if you ask nicely :p
| |
Team Chaos Leader
USA
| | (Moderator)
Posts 2094
14 Nov 2011 09:41
| Phil "meynaf" G. wrote:
|
My code has error handler calling some kind of "abort" primitive, with an error message. Standard behaviour from me is just to abruptly quit application with that message - perhaps this is not what you want for your game :) |
Ack! Definitely not what I want. :) This would great:
ErrorMsg=LoadImage(filename);IF (ErrorMsg) THEN // there was an error and ErrorMsg points to a string
PRINT(ErrorMsg);
END_IF
But u prob return an error# which I can deal with also :)Maybe it should work like this:
ErrorNumber=LoadImage(filename,ErrorMsg);
Then I get an Error Number and String both for the same price :)
Also I emit a lot of warnings for images with useless chunks, extraneous data, bad encoding... but these can be ignored.
|
I have no opinion about that.
Well, you know my mail already, so I can give you all the details if you ask nicely :p
|
When I forget ur mail I just look u up in the cyclopedia under "Hardcore Asm MegaC0der" :)
| |
Phil "meynaf" G.
France
| | (Natami Team)
Posts 393
16 Nov 2011 08:53
| Team Chaos Leader wrote:
|
Maybe it should work like this:
ErrorNumber=LoadImage(filename,ErrorMsg);
|
I'm afraid it won't work. There is no access to input data, and nowhere to output data...I have "input" calls to ask for next n bytes from the file, and "output" calls to send lines out.
| |
Amiga Believer
Canada
| |
Posts 282
17 Nov 2011 17:46
| It would be great to have PNG as a datatype, lots of programmes would then be able to use it instantly.
| |
Team Chaos Leader
USA
| | (Moderator)
Posts 2094
17 Nov 2011 17:57
| There are already PNG Datatypes. At least 2 different ones.
| |
Phil "meynaf" G.
France
| | (Natami Team)
Posts 393
20 Nov 2011 09:43
| And they are written in C. And they are slow :p
| |
Team Chaos Leader
USA
| | (Moderator)
Posts 2094
20 Nov 2011 10:10
| The worst thing about datatypes is that they are datatypes. :( The Datatypes system has 1 bad design flaw + 1 more tragically terrible design flaw. :( Other than that, datatypes are awesome. :)
| |
Thomas Richter
Germany
| | (MX-Board Owner)
Posts 1425
20 Nov 2011 13:13
| Team Chaos Leader wrote:
|
The worst thing about datatypes is that they are datatypes. :(
The Datatypes system has 1 bad design flaw + 1 more tragically terrible design flaw. :(
Other than that, datatypes are awesome. :)
|
Agreed. Datatypes are nice, but the interface is often too limited.
| |
Børge Nøst
Norway
| |
Posts 53
20 Nov 2011 20:15
| Team Chaos Leader wrote:
| | The Datatypes system has 1 bad design flaw + 1 more tragically terrible design flaw. :( |
Ok, I'll bite. Which ones?(I know streaming is not possible, that is one?)
| |
Wawa Tk
Germany
| |
Posts 581
20 Nov 2011 23:33
| exactly. could be extended, say, on aros.
| |
Samuel D Crow
USA
| | (Natami Team)
Posts 1295
21 Nov 2011 00:10
| @Wawa Tk
I think the AROS PNG datatype is extended, now that you mention it. The AROS version of Icon.library uses it for PNG icons. I think it contains a shared-library version of LibPNG.
| |
Wawa Tk
Germany
| |
Posts 581
21 Nov 2011 13:58
| i ment datatypes as the whole, if tere are restrictions that might be removed without losing backwards compatibility.
| |
Samuel D Crow
USA
| | (Natami Team)
Posts 1295
21 Nov 2011 15:40
| @Wawa Tk The restrictions are removed from Reggae classes in MorphOS but I don't think the AROS team would want to spend too much time backporting features from MorphOS when we don't even have all the features from AmigaOS 3.1 implemented.
| |
|
Do you have ideas and feature wishes? Post them here and discuss your ideas.