Overview Features Instructions Performance Forum Downloads Products OrderV4 Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
VISIT APOLLO IRC CHANNEL



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Information about the Apollo CPU and FPU.

Writing 3D Engine for 68080 In ASMpage  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 

Nixus Minimax

Posts 415
02 Jan 2020 13:32


Gunnar von Boehn wrote:

  The assembler can happily used absolute addressing - this is fine.
  The AMIGA OS will do this "rewrite" of your executable when its first loaded into memory.
  This means you can happily code using absolute addresses and they will be the correct addresses to the memory where the OS loaded you.

We are speaking about different things. No OS will turn a "MOVEA.w #$0400,a0" into something that points to an honestly gained portion of memory. Using labels and a lot of ds.b to spare the AllocVec() would work, of course.




Vladimir Repcak

Posts 236
05 Jan 2020 16:11


Kyle Blake wrote:

Sounds like most of these questions can be summed up as: "i only program for fixed hardware specifications, on bare metal. please explain the concept of an operating system to me".

I appreciate the attempt at a sarcasm, but I mentioned multiple times that:
- on Jaguar there is no OS where drivers/apps compete for RAM
- every Jag on planet has exactly 2 MB of RAM (zero HW fragmentation - this is waaaaaaay different than the Amiga HW space)

Therefore, as any good GameProgramming book will confirm, regardless of target platform (Jaguar, Saturn, Playstation), each game should make the best use of this situation by creating a game-specific dynamic memory allocation (which handles fragmentation as optimal as possible given the performance constraints of a specific game).

For example, the way I decided to handle it in my StunRunner-style game on Jag, is to handle all such processing and RAM allocations only during level-loading time.

This means that during gameplay, there is no need to alloc/dealloc any memory and I can process every array at full speed without a single worry about range checking, as all that happened during loading time.



Vladimir Repcak

Posts 236
05 Jan 2020 16:16


Nixus Minimax wrote:

Gunnar von Boehn wrote:

  The assembler can happily used absolute addressing - this is fine.
  The AMIGA OS will do this "rewrite" of your executable when its first loaded into memory.
  This means you can happily code using absolute addresses and they will be the correct addresses to the memory where the OS loaded you.
 

 
  We are speaking about different things. No OS will turn a "MOVEA.w #$0400,a0" into something that points to an honestly gained portion of memory. Using labels and a lot of ds.b to spare the AllocVec() would work, of course.
 
 

Well, he did mention before that as long as I only use labels (e.g. via dc.w), the OS will take care of it.

98% of all fixed addresses in my code are Blitter and ObjectProcessor specific (for reasons I mentioned before), meaning they won't be used on Amiga anyway.

The remaining 2 or 3 shouldn't take more than a day to refactor, as I can simply do ds.w 1048576, given that V2 has 128 MB RAM.


Wawa T

Posts 692
05 Jan 2020 16:18


thats clear, but why to force that approach on a computer that does have an operating system. except you want to treat it as a console and dispose of any advantages it actually has, compared to one?


Wawa T

Posts 692
05 Jan 2020 16:20


also i woulnt make assumptions about resources such as amount of ram. thats what an os is for. you assume 128mb ram, but v4 has 512, i hear. god knows what future versions will be. you want to hard code all that?


Vladimir Repcak

Posts 236
05 Jan 2020 16:46


Nixus Minimax wrote:

  AllocAbs() requests memory at a specified location. If that memory is already taken, the call will fail and your program will either crash (bad) or abort silently because it can't have what it needs (semi-bad).
 
I definitely intend to handle error OS checking/reporting in a generic way. There's going to be quite a few OS configurations of V2 and V4, after all. With some remote testing, a crash in itself provides almost zero info, but if I error check every single OS call using same method, that should be taken care of.
 

Nixus Minimax wrote:

  AllocMem(), btw, is deprecated anyway, better use AllocVec(). You may also consider the "Pool" functions (AllocPooled() and friends).
 

2 days ago I downloaded NDK 3.9 and am going through the include directories so I finally have full documentation and list of all OS functions.
Is 3.9 a good target or should I rather go for an older SDK ?

Nixus Minimax wrote:

  Don't treat the Amiga as a games console. You will have to adapt your code to variable addresses. If you are really desperate, you could probably use self-modifying code to just overwrite all the fixed addresses you are using now with the addresses of what the OS gives you on your AllocVec() requests and write these addresses right into your fixed-address code. Personally I think this would be rather dirty and probably more work than learning the clean way and rewriting your code to use variable addressing. Furthermore, if you do some tricks like calculating hardcoded addresses (e.g. something like MOVE.l a0,d0; BSET #10,d0; MOVE.l d0,a0 to switch screenbuffer or whatever), this will never work well on an Amiga.
 
  Just have a look at a few coding examples, it's quite simple and you have done infinitely more complicated stuff than this.
Sure, I was just initially hoping that porting my 68k code to Amiga would be much simpler.
Well, turns out, it's not :)



Vladimir Repcak

Posts 236
05 Jan 2020 17:12


wawa t wrote:

also i woulnt make assumptions about resources such as amount of ram. thats what an os is for. you assume 128mb ram, but v4 has 512, i hear. god knows what future versions will be. you want to hard code all that?

Oh, there's definitely going to have to be two different builds as there are two major configs:
V2 build : 128 MB
V4 build : 512 MB

On Jag, at one point, my main GPU RISC renderer had 16 different variations via compile-time flags. So, having just two shouldn't be any problem.

Since we will highly likely implement some form of optional texturing render path, V4 build can have higher-res textures. If you just double the resolution of textures, they take 4x more space.

128x4 = 512 :)

The uncompressed audio takes a lot of space at full precision. V2 might have to use lower frequency or less tracks.

It all depends on whether I'm going to do file-system (and load music tracks at level loading time) or not. I'd rather not open that particular can of worms just yet. Last two days of browsing turned out with over dozen tabs on filesystem gotchas/issues/arguments. There's no way I'm exposing myself to that kind of an aftermath...

Implementing LoadFile is about a day of work when you do it for the first time, but once it gets used on dozens of OS/libraries variations out there, it won't work on half of them or will have significant speed/other issues. Thanks, but no thanks :)

Now, if we could LOCK a particular OS, sure - I would then go and implement that as that would guarantee that nobody will have some older version that conflicts with something else.

But I don't think we can ask for something like that on Amiga, right ? Everybody seems to have a different set of libraries and related conflicts. Thank God for my PC gaming coding experience that has shaped my Microsoft library-version expectations accordingly :)



Vladimir Repcak

Posts 236
05 Jan 2020 17:23


wawa t wrote:

thats clear, but why to force that approach on a computer that does have an operating system. except you want to treat it as a console and dispose of any advantages it actually has, compared to one?

But how exactly is it an advantage from coding point of view ?

I don't see one - I only see dozens of bug reports and angry mob of paying customers who managed to create two dozens of other OS/lib configurations where the game doesn't run or crash or loads way too slow compared to other people or has other unforeseen issues.

I think I now finally see the point of actually just killing the OS completely.

Probably the best way to avoid all that meshuggah is by releasing some short downloadable demo which will confirm whether the thing even runs on your config or not.

Now, long-term, if this endeavor proves sustainable financially, the next game on same engine may go further and implement more OS-generic functionality.


Vladimir Repcak

Posts 236
05 Jan 2020 17:29


Gunnar von Boehn wrote:

  The V4 texture pipeline is WIP right now.
  We need time and people using it and feedback of coders to make it finished.

Would you be able to share some of the current performance characteristics - e.g. cycles it takes ?

1. Read Texel (u,v) - no filter
2. Read Texel (u,v) - bilinear

Both for S3TC and uncompressed textures ?

I'm going through some benchmarks I had on Jag and trying to figure out how fast texturing is on V4.



Kamelito Loveless

Posts 80
05 Jan 2020 21:48


NDK version?..., well it depends what OS functions you want to use. Maybe a poll should be made so every Vampire owners could vote and you’ll know.


Wawa T

Posts 692
05 Jan 2020 22:39


Vladimir Repcak wrote:

  I think I now finally see the point of actually just killing the OS completely.
 

  so you advise us to get rid of the operating system completely, because such a successful console as jaguar or a computer of an 8 bit era is much better alternative than contemporary approach with all this annoying multitasking and stuff. id like to remind you, you are talking to an amiga crowd, many of whom, for a reason or not, hold their operating system and its paradigms in high regard.
 
  of course this can be disputed. and you can develop according to your own principles of course. whether then anyone will drop the os and existing software base just to be using your library remains to be seen.
 
  im just not sure why you have chosen this particular platform for your experiment. you could have as well port your engine to pi or some microcontroler probably.


Stefano Briccolani

Posts 432
05 Jan 2020 23:22


Let's judge Vlad work and not his approach to Amiga. The best games on Amiga 500 Golden years used the same "console approach" disabling Os and coding the floppy trackloader without using OS.



Wawa T

Posts 692
06 Jan 2020 00:14


im fine with that. i guess everyone is. go ahead.


Vladimir Repcak

Posts 236
06 Jan 2020 01:32


wawa t wrote:

  so you advise us to get rid of the operating system completely, because such a successful console as jaguar or a computer of an 8 bit era is much better alternative than contemporary approach with all this annoying multitasking and stuff. id like to remind you, you are talking to an amiga crowd, many of whom, for a reason or not, hold their operating system and its paradigms in high regard.
 
  of course this can be disputed. and you can develop according to your own principles of course. whether then anyone will drop the os and existing software base just to be using your library remains to be seen.
 
  im just not sure why you have chosen this particular platform for your experiment. you could have as well port your engine to pi or some microcontroler probably.

I can see you'd like a flamewar, but I'm not gonna bite...



Wawa T

Posts 692
06 Jan 2020 01:48


no. not really.


Wawa T

Posts 692
06 Jan 2020 02:17


maybe ive been to blunt. certainly its curious why would you choose such an approach except exemplary trying some unorthodox abandoned way, that may have led to a different results. every approach is a trade off. also amiga has been a trade off at an earlier stage compared to the todays systems, or atari and macintosh of the era, technically, many will be urged to prove i bet. effectivity vs versatility is probably the point. therefore im puzzled why would you want to use such a platform, rather than trying to push one that is more set in stone and from the start geared towards your expectations, namely lacking an grown multitasking os.


Gerardo González-Trejo

Posts 37
06 Jan 2020 03:45


Vladimir Repcak wrote:

   
    I can see you'd like a flamewar, but I'm not gonna bite...
   
   

   
    Vladimir, when people are blunt or use sarcasm they do not try to attack you, they try to tell you something... I feel too much self-assessment on your posts. Is there any kind of reason for doing that? Because that makes many people not to understand what you want to communicate or makes them feel uncomfortable and/or surprised.
   
    Don't forget that you are writing on a Vampire - Amiga forum, where people are interested on Vampire - Amiga stuff. Still I would understand talking about Atari computers and their OS since may run too on Vampire. The Atari Jaguar was an amazing console (I had it one) but their followers (including me) are mostly on Atariage forums too.
   
    What many people want to understand is your target here: Talking us about your achievements and your 3d engine for Jaguar? Suggesting us that it is much better coding on bare metal? Getting support to start developing on Amiga? Sharing with us your working demo/game on an Amiga Vampire (not Jaguar)?
   
    I am sure that your thread will be much more interesting and productive for everybody if you focus on getting support, sharing you demo/game running on a Vampire or writing your feelings and experience when developing on Vampire - Amiga.


Mr Niding

Posts 438
06 Jan 2020 04:43


@Vladimir Repcak
 
  As I hinted at in the beginning of this thread;
 
  If you let forumthreads run wild, you will find no end to the posts :)
 
  Over the years Ive argued with Wawa T since he has a very blunt and rigid point of view. I often agree with him or his line of questions, but he has often shown a lack of willingness to view other peoples point of view, and express it clearly.
 
  THAT said; he is actually a very positive person for AROS, and you have to learn to ignore his "Elephant in a China-shop" approach.
 
  After several arguments Ive learned to read his posts with "I know he means well" goggles on, even tho he annoyed me :)
 
  At the end of the day; once you produce a fun/playable game that utilize the Vampire/Apollo core people will forget the art of endless semantics on forum(s)regarding OS or no-OS.


Nixus Minimax

Posts 415
06 Jan 2020 09:15


Vladimir Repcak wrote:
I definitely intend to handle error OS checking/reporting in a generic way. There's going to be quite a few OS configurations of V2 and V4, after all. With some remote testing, a crash in itself provides almost zero info, but if I error check every single OS call using same method, that should be taken care of.

Basically some kind of printf() giving a number of which allocation failed will do. Upon exiting the program, you free the allocated resources, usually in reverse order as you allocated them. If you keep variables in "variablename: dc.l 0" style, you can just load the variable and skip if it still is zero and hence was not initialised successfully. In this way you can cleanly exit your program without much ado.

2 days ago I downloaded NDK 3.9 and am going through the include directories so I finally have full documentation and list of all OS functions.
  Is 3.9 a good target or should I rather go for an older SDK ?

3.9 contains all the info on older OS versions, so you are OK with it. However, it would not code a program exclusively for any of the OS versions that came out after Commodore went bankrupt. For a game I'm not aware that you needed anything that later OS versions added. The last Commodore OS was 3.1.

3.5 and 3.9 came later and are in legal limbo. Now some developers picked up development back at 3.1 and brought 3.1.4 with long standing bugs fixed and totally new exciting bugs added. They are now working on a 3.2 version. The aim is to match 3.9 in features and improve upon it.

Then there is AROS which is intended to become the default OS for the Vampires. While scorned by many Amigans for its slowness, I can tell you that it has made leaps and bounds in the past two weeks or so and will be ready for limelight soon. AROS is an open-source reimplementation of the AmigaOS 3.1 API.

Summing up: the 3.9SDK is fine but code for 3.1 (or below)

 
I was just initially hoping that porting my 68k code to Amiga would be much simpler.
  Well, turns out, it's not :)

Well, you'll find that it's not that complicated. Basically you'll have to allocate memory, set up a screen and two or three screenbuffers, allocate audio channels, set up input message handling (e.g. via lowlevel.library) for keyboard and joystick or mouse, install a vertical blanking interrupt and/or timer(s) and that's pretty much all you need.



Nixus Minimax

Posts 415
06 Jan 2020 09:31


Vladimir Repcak wrote:
It all depends on whether I'm going to do file-system (and load music tracks at level loading time) or not. I'd rather not open that particular can of worms just yet. Last two days of browsing turned out with over dozen tabs on filesystem gotchas/issues/arguments. There's no way I'm exposing myself to that kind of an aftermath...

 
  I think you still haven't internalised the fact that an Amiga is a full-blown computer system with an operating system... :)
 
  You as a coder don't have to care about filesystems, their bugs or internals. You just open your file and load data from it using dos.library. You don't need to know about OFS, FFS, PFS and so on. The OS needs to know about them. You need to know a filename of your file, its path and that's it. AmigaOS can assign devices (similar to DOS's A:, B:, C: but with long names) to any directory of an underlying device. E.g. dh0: would be the first harddisk (a physical device) which has just some filesystem you don't need to know. On that harddisk your program will sit in a location the user selected according to his own preferences. The user then assigns Stunrunner: to that path (a logical device, because you requested him to do so in the manual to the game) and you load your files from Stunrunner:gamedata/music/level01 or whatever you think is appropriate. That's just one call to dos.library, nothing more (of course, opening dos.library took another library call to exec.library, the HQ of AmigaOS). That is about twenty lines of ASM code including the error checking.

 
Implementing LoadFile is about a day of work when you do it for the first time, but once it gets used on dozens of OS/libraries variations out there, it won't work on half of them or will have significant speed/other issues. Thanks, but no thanks :)

 
  No. This stuff has worked since 1985. It hasn't changed. It is very simple.
 
 

posts 425page  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22