Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
7 crawler(s) on-line.
 16 guest(s) on-line.
 1 member(s) on-line.


 Karlos

You are an anonymous user.
Register Now!
 Karlos:  3 mins ago
 Kronos:  13 mins ago
 matthey:  21 mins ago
 zipper:  37 mins ago
 amigakit:  59 mins ago
 pixie:  1 hr ago
 vox:  1 hr 45 mins ago
 BigD:  2 hrs ago
 Hypex:  2 hrs 7 mins ago
 MagicSN:  3 hrs 8 mins ago

/  Forum Index
   /  Amiga Gaming
      /  No, the limits of HAM have not vanished!
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 Next Page )
PosterThread
cdimauro 
Re: No, the limits of HAM have not vanished!
Posted on 3-Feb-2024 20:47:13
#41 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3709
From: Germany

@kolla

Quote:

kolla wrote:
@Karlos

To me, "software engineer" is a quite vague and wide term, while "coder" suggest someone who has quite particular skill in a particular field, often very close to the hardware and with very limited resources.

Well, maybe that's the problem: to you. Because this definition is certainly not correct neither acceptable.

A coder isn't "often" what you stated above: not at all! It's a so generic term which can even indicate a monkey typing something on the keyboard.
Quote:
Web frontends and apps are software engineers,

I beg to differ. Strongly. They can be coders (developers. Web developers and app developers, specifically), but not software engineers.

Being a software engineer does NOT automatically means "coder".
Quote:
while firmwares and device drivers for the OT market is more "coder" material.

Those are embedded developers.


@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote:
@cdimauro

How does a software engine work? I image it most be tiny to fit inside a computer.

Sorry, but I didn't get it. Could be please better clarify?

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: No, the limits of HAM have not vanished!
Posted on 3-Feb-2024 21:38:24
#42 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12856
From: Norway

@cdimauro

https://www.youtube.com/watch?v=RKT-sKtR970

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
Karlos 
Re: No, the limits of HAM have not vanished!
Posted on 3-Feb-2024 22:27:50
#43 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4485
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@NutsAboutAmiga

Engineering is a term that's grown to cover any technical or technological endeavour. I agree with the sentiment that it's overused, nevertheless it is the terminology that is used.

My job title says I'm an architect, but I don't design buildings.

_________________
Doing stupid things for fun...

 Status: Online!
Profile     Report this post  
cdimauro 
Re: No, the limits of HAM have not vanished!
Posted on 4-Feb-2024 5:29:50
#44 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3709
From: Germany

@Karlos: I agree.

When I started working at Intel I was a QA Engineer. When I left I was a Senior Software & QA Engineer.

When I joined my current company I was hired as "Software Entwikler" ("Software Developer". Germans are more precise ), but I was effectively working as QA & Testing Engineer.
Then I moved to Principal QA Engineer (and now I'm doing something different: management).

So, Engineer is a quite a broad term. As well as Architect. And Manager / Lead.

 Status: Offline
Profile     Report this post  
ppcamiga1 
Re: No, the limits of HAM have not vanished!
Posted on 4-Feb-2024 9:12:59
#45 ]
Cult Member
Joined: 23-Aug-2015
Posts: 829
From: Unknown

leave good old ocs for ocs games
for rest use in amiga better graphics parallel to ocs
drop aga it is worth nothign crap
every attempt to modernize ocs failed
don't change anything in ocs leave it as it is


 Status: Offline
Profile     Report this post  
Karlos 
Re: No, the limits of HAM have not vanished!
Posted on 4-Feb-2024 13:24:42
#46 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4485
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@cdimauro

Certainly in my experience, the progression is something like junior engineer, engineer, senior engineer, then it splits depending on the direction. You can go towards architecture if you want to stay technical or go towards lead/manager if you want to more team/project management.

As I have no interest in managing people and prefer to stay technical, I took the architectural route.

Last edited by Karlos on 04-Feb-2024 at 01:29 PM.
Last edited by Karlos on 04-Feb-2024 at 01:26 PM.

_________________
Doing stupid things for fun...

 Status: Online!
Profile     Report this post  
kolla 
Re: No, the limits of HAM have not vanished!
Posted on 4-Feb-2024 15:12:33
#47 ]
Elite Member
Joined: 21-Aug-2003
Posts: 3037
From: Trondheim, Norway

@Karlos & @cdimauro

You are illustrating my point - "the industry" (which is a vaaast span in itself) operates with so many fluffed up and watered out position terms (often bordering to nonsensical), that when someone apply and dare to simply use the term "coder", then cood on them, they got my interest.

My daily jobs these days are "senior operational manager", "technical lead", "solution architect", "senior network engineer", "SME" for a bunh of "matters", and probably half a dozen or more other "industry euphemisms". In short, I'm a sysadm.

My mom was a weaver, or as you would call it, "senior textile engineer".

Last edited by kolla on 04-Feb-2024 at 03:12 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
Karlos 
Re: No, the limits of HAM have not vanished!
Posted on 4-Feb-2024 16:59:34
#48 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4485
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@kolla

I'm not disagreeing. As I said above, I share the sentiment through term is overused.

None of which changes the observation that industry practitioners rarely, if ever, refer to their role as "coder".

Last edited by Karlos on 04-Feb-2024 at 05:06 PM.

_________________
Doing stupid things for fun...

 Status: Online!
Profile     Report this post  
cdimauro 
Re: No, the limits of HAM have not vanished!
Posted on 4-Feb-2024 17:47:00
#49 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3709
From: Germany

@ppcamiga1

Quote:

ppcamiga1 wrote:
leave good old ocs for ocs games

That's a tautology...
Quote:
for rest use in amiga better graphics parallel to ocs

Which rest?
Quote:
drop aga it is worth nothign crap

If AGA should be dropped, then what about your beloved PowerPCraps? They are even worse!

At least AGA is part of Amiga's history: PowercraPCs aren't...
Quote:
every attempt to modernize ocs failed
don't change anything in ocs leave it as it is

The article and discussion was/is about using OCS... as it is, dear CraPowerPC fanatical.

Now attach PC's keyboard and mouse to your NoAmiga PC-with-CPU-replaced-by-a-PowerPC-one and play your non-Amiga stuff there, hamster.


@Karlos

Quote:

Karlos wrote:
@cdimauro

Certainly in my experience, the progression is something like junior engineer, engineer, senior engineer, then it splits depending on the direction. You can go towards architecture if you want to stay technical or go towards lead/manager if you want to more team/project management.

*
Quote:
As I have no interest in managing people and prefer to stay technical, I took the architectural route.

After a very long time as developer, I decided for the opposite route: switch to management.

If I want to thinker coding, I prefer to do for my own projects. Or for some internal tool which helps on my current work.
Quote:

Karlos wrote:
@kolla

None of which changes the observation that industry practitioners rarely, if ever, refer to their role as "coder".

This. We use developer, not coder.

And certainly not assuming that a Software Engineer is a developer.

 Status: Offline
Profile     Report this post  
ppcamiga1 
Re: No, the limits of HAM have not vanished!
Posted on 4-Feb-2024 19:21:24
#50 ]
Cult Member
Joined: 23-Aug-2015
Posts: 829
From: Unknown

@cdimauro

use good old OCS for OCS games.
OCS games that has OCS style OCS look OCS character
no textures 16 color sprites 2 playfield 8 colors max
keep it as it is and as it was 40 years ago
16 bit 7 MHz clock no chunky bitplanes only 0.5 MB CHIP RAM only
chip ram as fast as it was 40 years ago

for anything else use better graphics connected to Amiga parrell to OCS
drop aga it is worth nothing



 Status: Offline
Profile     Report this post  
cdimauro 
Re: No, the limits of HAM have not vanished!
Posted on 4-Feb-2024 21:16:52
#51 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3709
From: Germany

@ppcamiga1

Quote:

ppcamiga1 wrote:
@cdimauro

use good old OCS for OCS games.
OCS games that has OCS style OCS look OCS character
no textures 16 color sprites 2 playfield 8 colors max
keep it as it is and as it was 40 years ago
16 bit 7 MHz clock no chunky bitplanes only 0.5 MB CHIP RAM only
chip ram as fast as it was 40 years ago

for anything else use better graphics connected to Amiga parrell to OCS
drop aga it is worth nothing




 Status: Offline
Profile     Report this post  
kolla 
Re: No, the limits of HAM have not vanished!
Posted on 5-Feb-2024 2:40:32
#52 ]
Elite Member
Joined: 21-Aug-2003
Posts: 3037
From: Trondheim, Norway

@cdimauro

You’re still a developer, just a different kind of developer.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
cdimauro 
Re: No, the limits of HAM have not vanished!
Posted on 5-Feb-2024 5:03:14
#53 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3709
From: Germany

@kolla

Quote:

kolla wrote:
@cdimauro

You’re still a developer, just a different kind of developer.

No, I'm a manager (System Integration Testing Lead, actually).

As I've stated before, I don't code anymore: I do it only if I've to update my own tool or create a new one because I need some other report, chart, status checkes.
However it's quite rare, since my activities are consolidated after some years (I know what I need and I've the right tools), and I need nothing else ('til now).

In my private life... I'm still tinkering with code, when I've some time (which is... rare, unfortunately).

 Status: Offline
Profile     Report this post  
Hans 
Re: No, the limits of HAM have not vanished!
Posted on 5-Feb-2024 5:24:51
#54 ]
Elite Member
Joined: 27-Dec-2003
Posts: 5074
From: New Zealand

@cdimauro

Quote:
Quote:
Ages ago I was also thinking about how to use HAM mode in a game. I came up with a few ideas which I never had time to try out.

First, HAM bobs could be made whose left-most pixels use the base palette (left-most in the shape, not the rectangular region). To stop the smearing on graphics underneath, you'd need an additional bitplane marking the pixels on the right-side of the bob shape. This would be used to replace any pixels below with the closest base palette colours to minimise the errors. Yes, this means that all imagery would need to have a second copy using the base palette.


Unfortunately this will stil produce fringing, and sometimes quite evident, because the pixels starting just to the right (letting X being the position of the pixel just after the right border of the BOB) of this one are "linked" to the background colour at position X.


Completely eliminating fringing is an unrealistic goal, at least with the processing power available on Amiga computers. Instead, the goal is to try to reduce the fringing to an "acceptable" level so that you can take advantage of HAM mode's greater number of colours... while still having enough processing power to create a fun game.

Yes, the base palette isn't the same as the actual pixel colour, but the average colour error is going to be a good step less than just pasting a bob on top and doing nothing (and the maximum error is greatly reduced). I can't comment on how visually annoying the remaining error would be, because I never got round to testing it out.

Thinking about it a bit more, you could write a HAM dithering algorithm to generate HAM images with a rule that every colour channel must be covered at least every n pixels (n being yet another trade-off, smaller means less fringing, but more noise in the original image).


Quote:
In HAM8 basically you've no slots available when displaying the screen. With HAM you've at least 25% of them.

This means that there's really too little bandwidth for producing something usable, if you consider that you've to move quadruple the graphics compared to the LORES.


Yeah, I remember shires being slow as a sloth on the A600.


Quote:
I would strongly avoid using interlace mode with games: I care about people's eyes.


Haha. I haven't forgotten the horrible flickering. However, interlaced TVs didn't flicker horribly due to proper antialiasing.


Quote:
That's a pity. Yes, RGB was becoming the standard, but YUV would have given to the Amiga a net advantage.


Here's a new idea. I a similar style to the Graffiti card, make a YUV to RGB converter module that you can plug into the RGB out port on the Amiga. Include a way for software to enable and disable it on-the-fly, and you've got yourself a YUV HAM mode.

Hans

Last edited by Hans on 05-Feb-2024 at 06:19 AM.
Last edited by Hans on 05-Feb-2024 at 06:16 AM.
Last edited by Hans on 05-Feb-2024 at 06:16 AM.
Last edited by Hans on 05-Feb-2024 at 06:11 AM.

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

 Status: Offline
Profile     Report this post  
Karlos 
Re: No, the limits of HAM have not vanished!
Posted on 5-Feb-2024 11:46:50
#55 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4485
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Hans & @cdimauro

It's certainly a documented fact that the inspiration for HAM came from Jay Miner's experience of flight simulator hardware that made use of it for shading purposes.

The question for me is, how do you envisage it as a total solution? Would palette entries still be RGB and the modifcation of values be entirely decided by the scan out hardware? Or would the palette be a YUV model also?

This matters since software colour manipulation is much more intuitive in RGB space. However, if the interpretation of the rest of the modified pixels following a palette entry was left purely to hardware chroma/saturation/luminance manipulation, trying to understand the colour of any pixel data you read back from the framebuffer becomes challenging, to say the least.

_________________
Doing stupid things for fun...

 Status: Online!
Profile     Report this post  
Hans 
Re: No, the limits of HAM have not vanished!
Posted on 5-Feb-2024 12:37:52
#56 ]
Elite Member
Joined: 27-Dec-2003
Posts: 5074
From: New Zealand

@Karlos

Quote:
The question for me is, how do you envisage it as a total solution? Would palette entries still be RGB and the modifcation of values be entirely decided by the scan out hardware? Or would the palette be a YUV model also?

This matters since software colour manipulation is much more intuitive in RGB space. However, if the interpretation of the rest of the modified pixels following a palette entry was left purely to hardware chroma/saturation/luminance manipulation, trying to understand the colour of any pixel data you read back from the framebuffer becomes challenging, to say the least.

You mean my external RGB to YUV suggestion? IMHO, keep it simple. If your using YUV mode, then let every pixel be YUV (including pixels that use palette entries). You'd be setting yourself up for a confusing mess if some pixels were RGB and others were YUV. Added to that, I don't see how external hardware would be able to detect which pixels are palette, and which ones are HAM.

One exception would be if the hardware could be programmed to make select rectangular regions YUV. That would be a bit like having overlay windows, except that you don't get to use a separate bitmap for it. Most important, is that it's much easier to keep track of the region(s) you set, than having to keep track of individual pixels.

EDIT: Having a programmable way to enable/disable RGB => YUV conversion was so that you don't have to unplug the converter or manually flick a switch just to see a normal RGB screen.

Hans

Last edited by Hans on 05-Feb-2024 at 12:43 PM.

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

 Status: Offline
Profile     Report this post  
Karlos 
Re: No, the limits of HAM have not vanished!
Posted on 5-Feb-2024 13:26:09
#57 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4485
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Hans

So, as I mentioned above somewhere, I experimented with YUV HAM in MC64K before just going with RGB again. The problem with YUV is that it's just not a remotely intuitive format for software colour manipulation. It might not matter if all you are doing is manipulating prerendered graphical elements on a buffer. It was also apparent in my 5-bit version (not HAM in general) that you need greater resolution for the luminance than your desired but depth can deliver.

_________________
Doing stupid things for fun...

 Status: Online!
Profile     Report this post  
cdimauro 
Re: No, the limits of HAM have not vanished!
Posted on 5-Feb-2024 19:18:31
#58 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3709
From: Germany

@Hans

Quote:

Hans wrote:
@cdimauro

Quote:
Unfortunately this will stil produce fringing, and sometimes quite evident, because the pixels starting just to the right (letting X being the position of the pixel just after the right border of the BOB) of this one are "linked" to the background colour at position X.


Completely eliminating fringing is an unrealistic goal, at least with the processing power available on Amiga computers.

Indeed, as it's clearly shown on the new Hamulet demo: even with carefully precalculated graphic animations you can see fringing.

There's no escape room, unless you want to put heavy requirements on the graphics, but then... continuing to insist using HAM doesn't make sense.
Quote:
Instead, the goal is to try to reduce the fringing to an "acceptable" level so that you can take advantage of HAM mode's greater number of colours... while still having enough processing power to create a fun game.

Fair enough.
Quote:
Yes, the base palette isn't the same as the actual pixel colour, but the average colour error is going to be a good step less than just pasting a bob on top and doing nothing (and the maximum error is greatly reduced). I can't comment on how visually annoying the remaining error would be, because I never got round to testing it out.

Maybe someone can take the chance and give a try. There are plenty of "old style coders (!)" which could find it fun.

Anyway, your method requires double the space (as you already stated) and double cookie-cut of the BOB (since you don't know where the right border of the BOB ends).
Quote:
Thinking about it a bit more, you could write a HAM dithering algorithm to generate HAM images with a rule that every colour channel must be covered at least every n
pixels (n being yet another trade-off, smaller means less fringing, but more noise in the original image).

Hum. Do you mean that if n == 3 then in 3 subsequent pixels each colour component should have been changed?
Quote:
Quote:
I would strongly avoid using interlace mode with games: I care about people's eyes.


Haha. I haven't forgotten the horrible flickering. However, interlaced TVs didn't flicker horribly due to proper antialiasing.

I don't recommend it anyway. I had my A1200 attached to a 16" TV of the time, and interlace was really horrible to sustain for long time.
Quote:
Quote:
That's a pity. Yes, RGB was becoming the standard, but YUV would have given to the Amiga a net advantage.


Here's a new idea. I a similar style to the Graffiti card, make a YUV to RGB converter module that you can plug into the RGB out port on the Amiga. Include a way for software to enable and disable it on-the-fly, and you've got yourself a YUV HAM mode.

Hans

I know the Graffiti. Yes, it could be implemented that way, but only in LORES (using HRES as the "master") or HRES (using SHRES as "master").

Or... it could be emulated.
Quote:

Hans wrote:
EDIT: Having a programmable way to enable/disable RGB => YUV conversion was so that you don't have to unplug the converter or manually flick a switch just to see a normal RGB screen.

That's the easy part. Graffiti uses some scanlines to send "commands" to the box which is handling the conversion. Those are the commands which enable it, and the same can be done for enabling YUV (and loading the YUV palette before the graphic is displayed).

This way it's totally transparent: by default you've the classic RGB mode, and by properly programming the external box you enable and have the YUV screen.

 Status: Offline
Profile     Report this post  
Karlos 
Re: No, the limits of HAM have not vanished!
Posted on 5-Feb-2024 22:23:50
#59 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4485
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@cdimauro

Quote:
At least AGA is part of Amiga's history


They were both a part of the history, really. The demise of AGA marked the end of an era. The demise of PPC marks the end of an error.

Last edited by Karlos on 05-Feb-2024 at 10:25 PM.

_________________
Doing stupid things for fun...

 Status: Online!
Profile     Report this post  
cdimauro 
Re: No, the limits of HAM have not vanished!
Posted on 6-Feb-2024 5:51:06
#60 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3709
From: Germany

@Karlos

Quote:

Karlos wrote:
@cdimauro

Quote:
At least AGA is part of Amiga's history


They were both a part of the history, really.

PowerPC accelerator boards, yes.

PCs with CPU replaced by a PowerPC one... no, they are not.
Quote:
The demise of AGA marked the end of an era. The demise of PPC marks the end of an error.

It was a big mistake already going for PowerPC instead of x86 when it was contracted to port the Amiga o.s. to some other platform.

But this wasn't Amiga anymore: just a part which was taking a different path. So, another story...

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle