Amiga-Development

Please login or register.

Login with username, password and session length
Advanced search  

News:

Created for developers of all Amiga camps

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - SamuraiCrow

Pages: [1] 2 3 ... 26
1
Announcements / Re: Tapatalk support
« on: August 08, 2017, 10:48:24 AM »
It added successfully now.  When Owl is released as open source, I might be able to rewrite it in Hollywood for better compatibility than most Amiga browser support.

2
Announcements / Tapatalk support
« on: August 08, 2017, 09:49:22 AM »
I'm trying to add support to this forum so that it can be viewed using the Tapatalk app and similar apps that use the same plugin such as Owl.  This has the potential to speed up access to systems with limited web browser support by using a custom app.

3
E33 (AmigaE) / Re: [E] ERROR: statement out of local/global scope
« on: May 08, 2017, 08:54:34 PM »
@thread

Topic moved to the proper place.  Since AmigaE version 3.3a is what is being used, that is the destination.

@magorium

This topic is about the original AmigaE not PortablE.

@r-tea

The OBJECT command must be before the PROC definition rather than inside it.

5
AmigaOS 3.x Dev / Re: Hunk symbols
« on: March 22, 2017, 12:19:46 PM »
Hunk is a graphical editor by ThoR for Hunk executables.  http://aminet.net/package/dev/misc/Exemine is another hunk dumper.  There is another that comes with AmigaE called ShowHunk, I think.

Overlay is some documentation by ThoR about Overlay hunks that are seldom used but may contain other info as well.

Sorry if this is irrelevant drivel, but what you seem to be looking for is a RELOC hunk to insert absolute addresses into your code.

6
SAGA / TinyGL ported to Vampire
« on: March 08, 2017, 08:14:40 AM »
http://aminet.net/package/dev/lib/libTinyGL

From readme:
Quote
TinyGL is intended to be a very small implementation of a subset of
OpenGL for embedded systems or games. It is a software only
implementation. Only the main OpenGL calls are implemented. All the
calls I considered not important are simply *not implemented*.

The main strength of TinyGL is that it is fast and simple because it
has not to be exactly compatible with OpenGL. In particular, the
texture mapping and the geometrical transformations are very fast.

7
AmigaOS 3.x Dev / Re: 24Bit Image on AGA/ECS
« on: February 08, 2017, 05:35:42 AM »
If you want to use datatypes to do so, you can import a true color image, but it will lose detail or color or both.  It requires AmigaOS 3 to use and won't work on earlier versions and also is included with AROS.

8
Languages / Re: FreePascal for all Amiga Systems
« on: February 07, 2017, 12:49:15 PM »
I've created a subforum of this one called Free Pascal with you as a moderator.  Welcome to AmigaCoding.de as a mod!

9
AmigaOS 3.x Dev / Re: 24Bit Image on AGA/ECS
« on: February 07, 2017, 12:33:49 PM »
ECS is limited to 4096 colors by the Video DAC and cannot display more than that no matter what.  AGA could use HAM8 though.

10
Aros 68k and Amiga 68k / Re: Comparation of AROS API and 3.5 API
« on: January 17, 2017, 12:37:59 PM »
@magorium

Thanks, I've updated my chart.

11
Aros 68k and Amiga 68k / Re: Comparation of AROS API and 3.5 API
« on: January 03, 2017, 04:24:45 PM »
Comparation AROS and Amiga OS 3.5
   
   

All trademarks used on this site, whether marked or not, are protected by law.
AMIGA3.5 is a registered trademark of Amiga, Inc. Use of the software or downloading is entirely and wholly at the users risk.
   
   
LibraryAmigaOS 3.5AROS
AmigaGuideYesNo use Amigaguide.datatype instead
Amiga_libYesNo (replaced by ALib)
ASLYesYes
AudioYesNo
BattClockYesYes
BattMemYesNo
BulletYesNo
CardResYesNo
CAMDNoYes
CDYesNo
CGFXNoYes
CGFXVideoNoYes
CIAYesNo
ClibpoardYesNo
CodeSetsNoYes
CommoditiesYesYes
ConsoleYesYes
CoolImagesNoYes
DatatypesYesYes
DiskYesNo
DiskFontYesYes
DOSYesYes
EFINoYes
ExecYesYes
ExpansionYesYes
eXpatNoYes
FileSysResYesNo
FreeType2NoYes
GadToolsYesYes
GalliumNoYes
GamePortsYesNo
GraphicsYesYes
GSMNoYes
IconYesYes
IdentityNoYes
IFFNoYes
IFFParseYesYes
ImageSupportNoYes
InputYesYes
IntuitionYesYes
JFIFNoYes
JPEGNoYes
KernelNoYes
KeyboardYesNo
KeyMapYesYes
KMSNoYes
LayersYesYes (as Hyperlayers)
LCMS2NoYes
LocaleYesYes
LowLevelYesYes
MathFFPYesYes
MathIEEEDoubBasYesYes
MathIEEEDoubTransYesYes
MathIEEESingBasYesYes
MathIEEESingTransYesYes
MathTransYesYes
MesaNoYes
MiamiYesNo
MiscYesYes
MUIMasterNoYes
MUIScreenNoYes
NarratorYesNo
NonvolitileYesYes
NVDiskNoYes
OOPNoYes
ParallelYesNo
PCCardNoYes
PixMan
PNGNoYes
PopupMenuNoYes
PosixCNoYes
PrinterYesNo
PrometheusNoYes
PThreadNoYes
RealtimeYesYes
ReqToolsNoYes
REXXSupportNoYes
REXXSysLibYesYes
SDLNoYes
SerialYesNo
TimerYesYes
ToolNoYes
TrackDiskYesNo
TranslatorYesNo
UtilityYesYes
WorkbenchYesYes
ZNoYes
Z2NoYes

12
Introduce me / Re: Who am I?
« on: July 30, 2016, 03:01:06 AM »
Wow!  Have you found a new place?

13
Programming Tutorials / Re: C Chapter 3: Pointer variables
« on: May 05, 2016, 08:06:19 AM »
Dot versus Arrow notation

In most modern languages the dot operator is used to indicate membership but in C it only indicates membership if you have a structure to refer directly to.  If you have a pointer to the structure you have two options:

  • *ptr.offset=value;
  • ptr->offset=value;

In option 1, you dereference the pointer with a unary asterisk as usual and use the dot operator to offset into the structure dereferenced by the pointer.  Unfortunately, the most common notation is option 2, the hyphen and greater-than symbol to make an arrow.  It's equivalent but more confusing.  What really gets confusing is when you have structures inside of structures and pointers to other structures with nested structures in them:

Code: [Select]
#include <stdio.h>

struct s1
{
  int a;
  int *b;
};

struct s2
{
  int c;
  struct s1 *d;
};

struct s1 e;
struct s2 f;
int g;

int main()
{
  g=10;
  e.a=0;
  e.b=&g;
  f.c=11;
  f.d=&e;
  printf("%i\n",f.d->*b);
  return 0;
}

Will print "10" and exit successfully to the prompt on the next line on the CLI.  Do you see any mistakes?  (I'm seriously asking, I think I got it right but it's so confusing I can barely tell.)

Notice I used "#include <stdio.h>" at the top to activate the printf command (and others) in the standard IO library linked at build time by the linker.  The preprocessor will be covered in a future chapter.

(Two edits later...)
Okay, NOW it looks right.

14
Programming Tutorials / Re: C Chapter 3: Pointer variables
« on: April 30, 2016, 04:46:55 PM »
The post-increment operator is executed after the value of the statement is evaluated.  For that reason, the increment itself is generated as an additional opcode in the compiler.  If you have a choice between post- and pre-increment form of an instruction, the latter is usually simpler code.  Likewise for decrement operations.

15
Programming Tutorials / Re: C Chapter 3: Pointer variables
« on: April 29, 2016, 05:27:13 PM »
@ALB42

If src or dst was used after the until clause of the repeat command mine would be more accurate equivalence because the increments would still be performed in the C code before the condition code was evaluated.  I agree your version would be similar.  I'm also not fond of C but prefer AmigaE, Hollywood or Basic.

I've used Pascal in high school/secondary school and at the 2-year college I attended afterward.  I've never used Object Pascal, however.

Pages: [1] 2 3 ... 26