Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: hayashi on August 30, 2009, 04:42:29 PM
-
Hi,
After looking into programming in E, I'm considering learning C++ with intentions of either programming games for, or porting them to, 68k Amigas. (Someone I may be working on games with is already learning C++/OpenGL, so I could possibly share non-graphical code with/bug him for help)
Does anyone know what sort of material I should be getting, in terms of software and tutorials? I know I'll need to find a C compiler, standard libraries, and the AmigaOS 3 APIs, and some tutorials both on C++ (easy to find, google would probably work for me here) and how to code for the APIs (much harder to find). I'll also need some sort of library for playing back ProTracker modules.
Thanks, Matt
-
You should head over to http://www.utilitybase.com for help. I would recommend staying with C on the Amiga although GCC supports C++ on the Amiga. C++ is rarely used on the Amiga and it's slower. GCC is a major pain to set up on the Amiga. VBCC is a light weight Amiga compiler that is much easier to work with on the Amiga but does not support C++.
VBCC is here...
http://sun.hasenbraten.de/vbcc/
GCC is from the GeekGadgets CD on backtoroots.org (good luck!)...
http://geekgadgets.back2roots.org/
You should have the ROM Kernal Reference Manuals for documentation. The Libraries is the most important. They can be found on the internet. They are not updated past AmigaOS 2.x. You should have the latest SDK for AmigaOS 3.9. It can be found here...
http://aweb.sunsite.dk/download.php
That might get you started. It's not easy developing in C on a low end classic Amiga. There is some ide's available that help like this...
http://devplex.awardspace.biz/
or Murk's (free) may work already...
http://utilitybase.com/forum/index.php?action=vthread&forum=3&topic=1791&page=0
-
http://aminet.net/mus/play/ptreplay_ahi.lha is what you want for playing ProTracker modules. (This archive includes MorphOS as well as AmigaOS 3.x library versions.)
-edit-
http://aminet.net/package/mus/play/ptreplay66 is the original hardware-banging version BTW.
-
C++ is rarely used on the Amiga and it's slower.
That's highly debatable. If you simply compile C sources with a C++ compiler there's no difference unless you're using a retarded compiler. C++ function objects can be inlined, while function pointers in C can not. Some sorting algorithms have proven to be many times faster on C++ due to this.
It is true that certain parts of the C++ language are slow, like using virtual functions in a tight loop. It's really a matter of knowing your language, knowing the little 'gotchas'.
In my experience, the main disadvantage with C++ is slower compiling, especially when using templates. But I'm a little tired of reading "use C instead" every time someone mentions C++ on the Amiga.
-
I agree with Matthey about staying with C and avoiding C++ on the Amiga. If you use any part of the standard library e. g. streams, vectors, list, etc. expect code bloat. That's not a problem if you have gigabytes of memory, but on Amiga systems, we're talking megabytes.
-
I use C++ on the 68k miggy all the time. It's fine, provided you know what you are doing. It's also a lot more convenient than C at times.
If you use heavyweight features like templates and RTTI, you'll get bloat, but metaprogramming and reflection aren't free.
On the other hand, you can create code that is effectively "C with classes", that is both compact and fast.
-
Has anyone mentioned AmiDevCpp? It's a cross-platform IDE (I can use in on WinXP), that will let you choose your target like 68k, or PPC, etc. It's pretty good, but I haven't had much time to really spend on it.
Since I'm a PC graphics guy, I don't know (or can find) anything about graphics programming on the old miggy, which is what I'm trying to do with it.
Here's the link to AmiDevCpp:
http://amidevcpp.amiga-world.de/index.php?HR_LANG=english
-
Yep I think the idea that C++ is slower is not accurate these days, it's similar to the idea the C is slower than assembler (modern compilers produce very efficient assembler).
Anyway I've been using C++ on my 1200 for a port of DOTT (http://eab.abime.net/showthread.php?t=45410).
I use StormC V4 which uses the GCC compiler and features an IDE with built in debugger which makes everything a lot easier. You can still buy StromC V4 new for about $50.
It will take you longer to learn C++ of course, I spent a year learning straight C before I started looking at C++.
-
@Hayashi
What made you decide to give up E? It's not as powerful as C++ but it's as efficent as some C compilers and a LOT easier than C++.
@Beast96GT
What do you want to know about Amiga graphics programming? You can find out a lot by getting the Amiga Developer CD version 2.1 and looking at the graphics libraries section of the RKRMs.
-
@SamuraiCrow: A friend and I have had an idea for an RPG, which (if it ever moves out of planning) will likely be made first for Windows (and maybe Linux etc) using C++/OpenGL. If this happens, I really want to make an Amiga version (not a straight port, of course), and using the same language will of course help as we can trade core game code.
I was looking at trying to learn E, but now believe it's useless to spend time learning it when I could be learning a language that would both lend itself well to the above situation and be useful outside the Amiga.
-
I was looking at trying to learn E, but now believe it's useless to spend time learning it when I could be learning a language that would both lend itself well to the above situation and be useful outside the Amiga.
To be fair, this is why I've never really bothered with amiga specific programming languages. Whatever I can't implement efficiently in C/C++, there's always assembler :D
-
@Beast96GT
What do you want to know about Amiga graphics programming? You can find out a lot by getting the Amiga Developer CD version 2.1 and looking at the graphics libraries section of the RKRMs.
On the PC I used BitBlt (Win32 C++) to write to a 32-bit back buffer that's swapped to the front buffer for a GDI game I wrote. Now I work with OpenGL and DirectX that provide higher level access to graphics programming (I'm a console game developer), though still through C++.
I was kid when I had my Amiga and know nothing of the architecture. I'm a very experienced C++ programmer, but I simply don't have the time to try and figure everything out from scratch with regards to the Amiga. Maybe I can make it a process, but resources are what I need--else I get frustrated and take large breaks.
What can you tell me about this Ami Dev CD, and what are the RKRMs? Thanks.
-
@Beast96GT
RKRM stands for ROM Kernal Reference Manual. Libraries and Devices are the most important ones. Look here for more...
http://gega.homelinux.net/AmigaDevDocs/
Also get the SDK for 3.9 from the AWeb site I listed above and look at the autodocs.
Here is a guide to setting up an Amiga C programming environment...
http://code.google.com/p/guidetoamigacompatibleprogramming/
Warp3D developer archive...
http://aminet.net/dev/misc/Warp3DDev-4.2a.lha
StormMesa developer archive...
http://aminet.net/util/libs/StormMesa_Dev.lha
Info on developing in 3D on Amiga...
http://vague.lorraine-design.com/the_vague_1.html
-
Yep I think the idea that C++ is slower is not accurate these days, it's similar to the idea the C is slower than assembler (modern compilers produce very efficient assembler).
C IS slower than assembler. GCC's code optimization is a joke. Why is ffmpeg for the 68060 twice as fast with a few assembler routines compared to all C routines? I don't know much about C++ compared to C but I have seen too much assembly output from C programs to believe C is as fast as assembler. Plus I can beat it 95% of the time with assembler.
-
C IS slower than assembler. GCC's code optimization is a joke. Why is ffmpeg for the 68060 twice as fast with a few assembler routines compared to all C routines? I don't know much about C++ compared to C but I have seen too much assembly output from C programs to believe C is as fast as assembler. Plus I can beat it 95% of the time with assembler.
Well obviously over the years C/C++ compilers have improved massively and these days you'll improve performance more from looking at what the code is doing from a high-level rather than trying to hand-optimize algorithms (the quickest code is code you don't actually execute).
I remember reading an assembler 'tuning' article which had an exercise to improve some compiler generated assembler by-hand. When I went to make the change myself, I found that my newer version of the compiler had already produced exactly the same assembler as the article suggested ;)
I wasn't talking specifically about GCC, I was talking about modern compilers C++ in general.
-
C IS slower than assembler. GCC's code optimization is a joke. Why is ffmpeg for the 68060 twice as fast with a few assembler routines compared to all C routines? I don't know much about C++ compared to C but I have seen too much assembly output from C programs to believe C is as fast as assembler. Plus I can beat it 95% of the time with assembler.
This may be true for m68k compilers of the vintage in use on the amiga, but it isn't necessarily true of compilers in general. In any event, C and C++ both let you use assembler where you aren't satisfied with the compiler's code generation efforts.
Writing something entirely in assembler is massively wasteful in terms of development time.
-
Get a copy of Cubic IDE http://devplex.awardspace.biz/
It is a powerful package for programming C/C++, Hollywood, HTML and much more. It comes with vbcc and gcc (for sevral amigaish OSes) as well as a lot of documentation. The project mangement helps you with makefiles and to do your first "hello world" programm in C++ it takes only a couple of minutes.
Cubic is IMO one of the last software gems on Amiga & Co.
-
This may be true for m68k compilers of the vintage in use on the amiga, but it isn't necessarily true of compilers in general. In any event, C and C++ both let you use assembler where you aren't satisfied with the compiler's code generation efforts.
Writing something entirely in assembler is massively wasteful in terms of development time.
You mean non-68k compilers in general. GCC 4.4.x generates slow code for the 68k and sometimes buggy because 68k today means only embedded controller use and not mainstream computing any more. It generates much worse code than for a PowerPC or Intel x86.
-
NOOB QUESTION INCOMING
Does the 3.9NDK work with C++ or just C?
-
A few of the headers may require modification to work under C++ but don't ask me which ones. They will all work under C though.
-
NOOB QUESTION INCOMING
Does the 3.9NDK work with C++ or just C?
It works fine with both, with one caveat. In C++, the use of the struct keyword when referring to a type is deprecated. This can lead to an ambiguity (it happened to me once) where you have global variables and structures with the same name.
Somewhere in your NDK, you have:
extern struct IntuitionBase* IntuitionBase;
Now, this is isn't great. It isn't a good idea to mix up variable names and structure names.
However, in C:
IntuitionBase = (struct IntutionBase*)OpenLibary("intuition.library", 0);
is fine. The global variable on the left of the assignment is completely distinct from the typename on the right, due to the struct keyword.
In C++, this above use of the struct keyword is deprecated and can cause your compiler to moan. However, removing it, can cause a problem:
IntuitionBase = (IntutionBase*)OpenLibary("intuition.library", 0); // huh?
The compiler may not know how to interpret the left hand side. Is it an incomplete reference to something?
The solution that worked for me is to disambiguate the reference by explicitly pointing out the global namespace, using the scope of resolution operator ( :: ), thus:
::IntuitionBase = (IntuitionBase*)OpenLibrary("intuition.library, 0);
Now the compiler knows you mean the global variable called IntuitionBase, and not the type name IntuitionBase.
A few of the headers may require modification to work under C++ but don't ask me which ones. They will all work under C though.
If you keep the caveat above in mind, this isn't the case.
-
Yep I think the idea that C++ is slower is not accurate these days, it's similar to the idea the C is slower than assembler (modern compilers produce very efficient assembler).
Anyway I've been using C++ on my 1200 for a port of DOTT (http://eab.abime.net/showthread.php?t=45410).
I use StormC V4 which uses the GCC compiler and features an IDE with built in debugger which makes everything a lot easier. You can still buy StromC V4 new for about $50.
It will take you longer to learn C++ of course, I spent a year learning straight C before I started looking at C++.
Some books, or articles have suggested that learning C first before learning C++ may actually slow down the learning process and that learning C first is not necessary, or really desirable. Is that accurate in your opinion, or do you think that it helped you by learning C first then moving on to C++?
-
I don't really see the point of learning C first, just learn C++. Once you understand C++, C will become apparent.
-
@NovaCoder
C optimizing is getting better but it's not there yet with GCC 68k. GCC will do a pretty good job on some things and then add a nop or exg d0,d0 in there. I've been debugging Warp3D lately to try and fix a bug and I keep seeing those darn exg d0,d0. The wasted instructions even make for difficult reading. I wan't to fix everyone of them. For all the poor code, GCC code amazingly rarely crashes. The newest versions of GCC are worse at optimizing than the older versions by the way. I wouldn't be surprised if VBCC and SASC generate better code.
-
Some books, or articles have suggested that learning C first before learning C++ may actually slow down the learning process and that learning C first is not necessary, or really desirable. Is that accurate in your opinion, or do you think that it helped you by learning C first then moving on to C++?
Yep I think it helped me to learn C first (although it was a bit boring). It's quite a big brain-space jump to think about proper object orientation and you don't want the extra strain of learning the language syntax.
I'd only used Basic before getting into C/C++ so it was a steep learning curve for me :)
-
I use Python as my main language, so I already have some idea of the concepts behind object-oriented programming.
-
I'm a fairly good objective C programmer, how different is C++ to Obj C?
-
I don't really see the point of learning C first, just learn C++. Once you understand C++, C will become apparent.
That seems to be the popular thinking these days. That it is pointless to learn C anymore and more efficient to just jump into C++ as long as the person learning has some programming experience in any other language, or a very basic understanding of logic and perhaps some kind of scripting.
-
Anyobdy have a m68k GCC w/ SDL folder that works that they can just zip and send.
I can not get SDL to work for the life of me. Tried both GCC 3.4 and 4.3.2 which work fine, but I can't get SDL to work. ( Using 1.2.13(r2) )
Or at least confirm they work together on OS3.9 just so I can sleep at night! ;-)
Visual studio is like 4GB now, but at least I can just hit build. Ah, programming for dummies.
-
Got it working finally. Compiled my first SDL demo.
-
@NovaCoder
C optimizing is getting better but it's not there yet with GCC 68k. GCC will do a pretty good job on some things and then add a nop or exg d0,d0 in there. I've been debugging Warp3D lately to try and fix a bug and I keep seeing those darn exg d0,d0. The wasted instructions even make for difficult reading. I wan't to fix everyone of them. For all the poor code, GCC code amazingly rarely crashes. The newest versions of GCC are worse at optimizing than the older versions by the way. I wouldn't be surprised if VBCC and SASC generate better code.
SAS/C is probably the best C compiler you can find for 68k. I havent used GCC 68k but VBCC is known to have problems with register allocation and generates sometimes slower code. StormC 3 generates only crappy code but StormC 4 should be ok.
Anyway when coding it is better code everything in C than in assembler. It is maybe slower on 68k but you can write and optimize code at algorithm level much better and faster than you ever would if you were writing everything in asm. Assembler is good for optimizations when you can not tune C code any further.
-
@NovaCoder
C optimizing is getting better but it's not there yet with GCC 68k. GCC will do a pretty good job on some things and then add a nop or exg d0,d0 in there. I've been debugging Warp3D lately to try and fix a bug and I keep seeing those darn exg d0,d0. The wasted instructions even make for difficult reading. I wan't to fix everyone of them. For all the poor code, GCC code amazingly rarely crashes. The newest versions of GCC are worse at optimizing than the older versions by the way. I wouldn't be surprised if VBCC and SASC generate better code.
i think warp3d is written with stormc3 because its begin lots before stormc 4 come, and need because of lib some specific compiler stuff so it cant without extra work run on stormc4 which use gCC.
that storm mesa is written with stormc3 you can see in the sources, there are asm files attach, stormc3 generate out of C source.
The most problem in C++ and all OO languages is, that its complete diffrent than a CPU work, and C++ allow lot features to write horribly slow programs that look in a csource only as a simple = and simple Term.
So i think its always usefull for write fast programs, that devs know about asm language, so they can see in debugger or profiler wy this program is so horribly slow.
But most programmers do not care about asm and dont know about the instruction their CPU use.and because X86 is a cisc cpu asm source is not so long as risc source, but still most dont know about X86 asm.
And thats the reason wy OO programs are mostly slower as C Programs and that win and linux programs need GHZ CPU to run well these days.
and as we see in kde or safari there is spend much work to speed up.
So the question is, is it faster to use C++ and go often in slowdown traps, and need time to speedup and rewrite code so it look maybe not so OO clean.
I for myself dont like C++, it cost me lots more time, also on compiling.then this strange errors...
Maybe when there are entry level 10 GHZ 16 Core CPU out, maybe i change my mind. ;-)
then i think there need no speed optimization and it happen very very selden that you run in a C++ slowdown trap that make the program slow working.
-
Sorry to gravedig, but I'm now trying to use the AHI-based ProTracker module library linked to earlier in this topic, and playback is horribly slow, freezes the program, and I haven't a clue how to properly use it. Could anyone help, please?
Thanks, Matt
-
I`ve been developing games for directx some time now and always user a mixture of c and c++. I find that object oriented code clarifies your code a lot and helps with the debugging. Since, i`m thiking of returning to the roots and developing something on the AMIGA I would like to know which c++ compiler you recommend after all?
Is this stromC 4 compiler the best available? Is it still commercially available?
best regards
George
-
Is this stromC 4 compiler the best available? Is it still commercially available?
Alinea Computer (http://www.alinea-computer.de) is the current owner/seller of StormC4. It's listed in their online store.
-
Get a copy of Cubic IDE http://devplex.awardspace.biz/
It is a powerful package for programming C/C++, Hollywood, HTML and much more. It comes with vbcc and gcc (for sevral amigaish OSes) as well as a lot of documentation. The project mangement helps you with makefiles and to do your first "hello world" programm in C++ it takes only a couple of minutes.
Cubic is IMO one of the last software gems on Amiga & Co.
I used Cubic IDE, and its documentation is a joke, examples are few.
In the past i wanted help in trying to add LUA support to my project, and was basically given the middle finger for my efforts, this was a while ago.
Anyway we do need a C++ developer site, we need to code like the software houses so we can have tools that they can quickly use to compile to our platform.
We Amigans are stubborn and still love our assembler programming, this is why apps are so few - the world has moved on in OOP creating apps insanely quickly.
with 1 ghz processors we can afford a performance hit, in return for portability a development speed.
The industry standard is C++/C#/.Net we need to catch-up bigtime or we will never get all the great apps tools and Multiplayer games that our platform deserves.
Amiga was known for its games - but our super fast chipset dependent assembly language is stuck in code rot, assembler is not portable, hard to update, the hardware is not portable its high time we start thinking about platform independent coding.
Not just code that has calls that are OS interdependent, but libraries and GFX layer and GUI also independent.
In some cases our beloved datatype system is causing problems with porting HAM software or compression tools that use powerpacker for example.
Using datatype in apps stops porting of the app to windows for example, as no one knows how to create HAM modes / AGA export routines manually in code.
Look at windows paint packages all they possibly have is IFF/ILBM file format.
-
SAS/C is probably the best C compiler you can find for 68k. I havent used GCC 68k
Years ago I used geekgadgets port of GCC (iirc 2.95), when I compared it to SAS/C I found GCC to be faster.
I tried various code generation options and I think telling GCC to generate 68000 code was the fastest across all processors.
-
Hey, a C++ thread waking up :-) (any zombie thread rules on this forum?)
Are people doing C++ coding on Amiga these days?
What about tools and compilers, IDE:s, SDK, debuggers, etc? Are they sufficiently up to date and on par with other platforms, or do people miss any significant features?
As I'm doing a 1.3 million line C++ Amiga project at the moment, I'm a bit curious to know if there is interest in C++ in general, and if there are any particular blockers.
//A.
-
Anyway we do need a C++ developer site, we need to code like the software houses so we can have tools that they can quickly use to compile to our platform.
We Amigans are stubborn and still love our assembler programming, this is why apps are so few - the world has moved on in OOP creating apps insanely quickly.
Assembler versus HLL doesn't really have as much to do with development time as people think it does. Bedroom coders used to develop games in assembler in the space of a few months. It's more about scale of the project and going in with a definite plan but knowing what to cut if the schedule slips - tooling really is secondary to good software-development practices.
Besides, 68k assembler is nearly a high-level language anyway, particularly with a good macro-assembler. (And C++, being C-derived, is a lot closer to being a low-level language than any other object-oriented language!)
with 1 ghz processors we can afford a performance hit, in return for portability a development speed.
That philosophy is the entire reason modern PC software is such a mess.
The industry standard is C++/C#/.Net we need to catch-up bigtime or we will never get all the great apps tools and Multiplayer games that our platform deserves.
.NET is a prime example. Whatever its actual merits, it's largely being used as a poor man's UI toolkit the way Visual Basic used to be - but where the Visual Basic runtime was less than a megabyte, .NET takes up hundreds. (And, of course, it imposes a speed penalty just like every interpreted language ever has done - and it may seem like nothing much on your 2GHz i5, but it'll add up pretty damn quick on even a 1GHz G4 system, let alone anything slower.)
C++ can be lightweight, in the right hands - .NET will never be. The Amiga community does not need to see software that could be broadly useful stuck behind the wall of a massive runtime which it probably doesn't even need a tenth the functionality of.
Amiga was known for its games - but our super fast chipset dependent assembly language is stuck in code rot, assembler is not portable, hard to update, the hardware is not portable its high time we start thinking about platform independent coding.
Not just code that has calls that are OS interdependent, but libraries and GFX layer and GUI also independent.
The last thing we need is to join in the gradual transformation of every damn program on every platform into a generic POSIX/Qt mess that fits equally poorly on every operating system and requires pack-in support libraries for everything past C stdlib functionality, in the name of "platform independence."
It's one thing to port platform-independent apps from other OSes for the sake of filling some need that isn't adequately filled by native software (browsers, for instance.) It's another thing entirely to suggest that we should no longer have native software. Abstracting away everything that is different on one particular target for the sake of having only one codebase leads to what is essentially running an entire operating system on top of the operating system.
In some cases our beloved datatype system is causing problems with porting HAM software or compression tools that use powerpacker for example.
Using datatype in apps stops porting of the app to windows for example, as no one knows how to create HAM modes / AGA export routines manually in code.
Look at windows paint packages all they possibly have is IFF/ILBM file format.
So, what, Amiga developers should hamper themselves and their users by eschewing any functionality that isn't supported on other operating systems? Why should the principal concern of an Amiga developer be "will Windows users be able to run this?" If another OS doesn't support features that the Amiga does, then boo-friggin'-hoo for the other OS.
If having all of your software work equally poorly on every platform because it's actually written for some mythical golden-mean target OS is so important, let me suggest that Linux already exists, sir.
-
Hey, a C++ thread waking up :-) (any zombie thread rules on this forum?)
Are people doing C++ coding on Amiga these days?
//A.
I don't do any C++ coding on my Amiga (too painfully slow), I still use gcc (cross compiler) on my PC.
Any 'modern' Amiga 68k targeted C/C++ development is very hard to do, the tools are just not up to the job. I once spent weeks trying to debug a nasty memory related issue while porting ScummVM to 68k, this issue only seems to effect the 68k version of gcc and in any case, if I'd had a debugger I could have fixed the problem in about 5 seconds flat.
-
.NET takes up hundreds. (And, of course, it imposes a speed penalty just like every interpreted language ever has done - and it may seem like nothing much on your 2GHz i5, but it'll add up pretty damn quick on even a 1GHz G4 system, let alone anything slower.)
It's not interpreted, it's just in time compiled. You can even pre-compile it on desktop/server operating systems.
The code generation isn't the problem, it's the bad code that gets through because the bar has been lowered & made it easier for rubbish programmers to get jobs.
Good algorithms in C# aren't slow. You can do good things on a 600mhz ARM processor for instance (and I have).
-
It's not interpreted, it's just in time compiled. You can even pre-compile it on desktop/server operating systems.
The code generation isn't the problem, it's the bad code that gets through because the bar has been lowered & made it easier for rubbish programmers to get jobs.
JIT is better than classic interpreted languages, yes. It still imposes a penalty, and it still makes zero sense in this age of free reasonable-quality compilers for every major architecture and most minor ones, especially when you're targeting a platform you know has one of two (maybe three) architectures.
You're right, though, that actually being a good programmer makes more of a difference. That's true in just about any case.
-
JIT is better than classic interpreted languages, yes. It still imposes a penalty, and it still makes zero sense in this age of free reasonable-quality compilers for every major architecture and most minor ones, especially when you're targeting a platform you know has one of two (maybe three) architectures.
In the right circumstances, JIT can outperform statically compiled code. Many things which are variables at compile time, end up being nearly constant at run time, whether they are some settings values or infrequently changing variables. Wherever conditional code depends on these, a clever JIT can fold out code in it's translation cache until those variables actually change. You can imagine the effect this can have on tight loops were you are able to remove a bunch of checks because you happen to know that at this instant during run time a whole load of them are invariant.
Even cleverer JITs don't bother compiling code that isn't compute bound and simply interpret it until a hotspot is found, reducing translation overhead as much as possible.
Using a combination of both, HP wrote a JIT called dynamo which actually "emulated" the same processor it was running on. Thanks to the effect of this late "run time" optimisation of code, it was able to outperform... itself :lol:
That is to say, a given piece of code executed directly on the CPU was slower than the same piece of code ran through dynamo on that CPU.
I've often though such an implementation would be ideal for something like coldfire because translation costs would be almost nothing and by running your 68K code through such a JIT, you can essentially catch the unimplemented opcodes/addressing modes as part of the translation steps, sidestepping the issue of whether or not you have any cases that you can't trap and emulate in the traditional fashion.
-
@ andst
What about tools and compilers, IDE:s, SDK, debuggers, etc? Are they sufficiently up to date and on par with other platforms, or do people miss any significant features?
I've tried many of them, from SasC, to Storm and Cubic on the Amiga. SasC and Storm come with debuggers, but I've only had luck with the Storm one. Like NovaCoder, I've had the most success using a GCC in conjunction with Eclipse, but, sadly, no debugger for it, although it may be possible to set up a remote debugger. I'm still figuring that one out.
@ NovaCoderAny 'modern' Amiga 68k targeted C/C++ development is very hard to do, the tools are just not up to the job. I once spent weeks trying to debug a nasty memory related issue while porting ScummVM to 68k, this issue only seems to effect the 68k version of gcc and in any case, if I'd had a debugger I could have fixed the problem in about 5 seconds flat.
It may be possible to do remote debugging with Eclipse. I'm currently researching how it might be done. The tools appear to be there, so I'm just not certain how to set them up or if they will play well together yet.
I've opened up a query over on the new meant-to-be-a-Utilitybase-replacement forum (http://www.amigacoding.de/index.php?topic=82.0). Anybody who has any ideas is welcome to comment either here or there on the subject.
-
To be fair, this is why I've never really bothered with amiga specific programming languages. Whatever I can't implement efficiently in C/C++, there's always assembler :D
Whaaa? No AMOS Pro??
-
@ andst
I've tried many of them, from SasC, to Storm and Cubic on the Amiga. SasC and Storm come with debuggers, but I've only had luck with the Storm one. Like NovaCoder, I've had the most success using a GCC in conjunction with Eclipse, but, sadly, no debugger for it, although it may be possible to set up a remote debugger. I'm still figuring that one out.
@ NovaCoder
It may be possible to do remote debugging with Eclipse. I'm currently researching how it might be done. The tools appear to be there, so I'm just not certain how to set them up or if they will play well together yet.
I've opened up a query over on the new meant-to-be-a-Utilitybase-replacement forum (http://www.amigacoding.de/index.php?topic=82.0). Anybody who has any ideas is welcome to comment either here or there on the subject.
Hiya,
Yep I did manage to get Eclipse CDT 'working' using the AmiDevCpp cross compiler setup. It managed to compile some of my project then started giving me errors about missing includes that were actually there. I've now gone back to AmiDevCpp which may not have as many features as Eclipse CDT but at least it works. I also tried CubicIDE and got nowhere, pain in the bottom.
I think it may be possible to hack in the gcc debugger to work from the shell but I doubt you'd be able to integrate it to CDT.
Trying to do any large scale C/C++ development without a debugger is like trying to fly a plane at night......with your eyes shut ;)
-
Yep I did manage to get Eclipse CDT 'working' using the AmiDevCpp cross compiler setup. It managed to compile some of my project then started giving me errors about missing includes that were actually there. I've now gone back to AmiDevCpp which may not have as many features as Eclipse CDT but at least it works. I also tried CubicIDE and got nowhere, pain in the bottom.
What types of projects are you talking about? I have some issues with some projects started in other tools not compiling, and with MUI apps, including any I start, but my other projects compile consistenly with only minor issues.
I think it may be possible to hack in the gcc debugger to work from the shell but I doubt you'd be able to integrate it to CDT.
I'm not talking about integrating anything with the CDT. :) I'm talking about using the CDT's remote debug capabilities to listen for either GdbStop or GdbServer on the target machine. Like I said, I /think/ it's possbile, but without trying, there's no way to know for sure.
Trying to do any large scale C/C++ development without a debugger is like trying to fly a plane at night......with your eyes shut
Yea. Exactly why I'd like to find out if it's possible. :D
-
Whaaa? No AMOS Pro??
I did once try AMOS just to see what it was like. No offence to the author, but it was terrible. Absolutely everything about it felt alien and wrong. Not just the language, but the entire runtime and environment. Blitz Basic seemed much better from just about any angle you can compare them.
-
It's cool Blitz Basic is still around.
http://www.blitzbasic.com/
-
I did once try AMOS just to see what it was like. No offence to the author, but it was terrible. Absolutely everything about it felt alien and wrong.
Amos is too much like old school Basic dialects, and people who are used to newer languages, C/C++ or Assembler, are not going to like it.
-
@thread
Dont forget this wrapper library, I think Sam was attempting toget the source code a while back.
http://oop4a.benderirc.de/oop4a_e.html
discussion here
http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=30196&forum=27&start=0&viewmode=flat&order=0
-
Once you get used to abstract data types/structures and proper functions, AMOS becomes quite frustrating... And this is where Blitz holds up much better... But that said, AMOS is a great teaching language :)
-
Once you get used to abstract data types/structures and proper functions, AMOS becomes quite frustrating...
Same for assembly language. Having to do things the Amos way sucks turds after getting used to assembler.