@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?

@cdimauro

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

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

@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...

@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.

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

@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...

@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

@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...

@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.

@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

@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

@cdimauro

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

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@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).

@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.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@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...

@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.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@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...

@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.

@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...

@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...