English Amiga Board


Go Back   English Amiga Board > Main > Retrogaming General Discussion

 
 
Thread Tools
Old 06 January 2016, 22:47   #81
ovale
Registered User

 
Join Date: Jun 2014
Location: milan / italy
Posts: 143
I see arcades machines like idiots savant. Their hardware is usually way more powerful than required by the game for which they have been designed and super aimed to specific tasks.

I guess this is a consequence of having hardware designers on the team and keep stuff extremelly simple on the software side to further experimentation.

This ended when arcades switched to platforms derived from consumer electronics like ps2, pc, etc...
ovale is offline  
AdSense AdSense  
Old 07 January 2016, 00:16   #82
switchblade
Registered User
 
Join Date: Apr 2009
Location: United States
Age: 31
Posts: 95
Quote:
Originally Posted by ovale View Post
I see arcades machines like idiots savant. Their hardware is usually way more powerful than required by the game for which they have been designed and super aimed to specific tasks.

I guess this is a consequence of having hardware designers on the team and keep stuff extremelly simple on the software side to further experimentation.

This ended when arcades switched to platforms derived from consumer electronics like ps2, pc, etc...
That's because arcade machines were only designed for a single purpose, and nothing more than that. It was probably easier or cheaper to throw extra hardware into an arcade machine, if they needed to do things the original hardware specs weren't capable of doing.

That is what I meant when I say that it's not a valid comparison to compare the Amiga's Copper to a highly specialized, purpose-built, piece of hardware like an arcade machine. It's like comparing a gaming laptop to a supercomputer specifically designed to model black holes in distant galaxies. Sure, they might share some specific functions here and there, but they don't even come close to being similar.

Anyway, none of it has anything to do with bringing Mega Man X to the Amiga, which is completely doable. Yes, the Amiga port will have compromises here and there, but it's not like anyone was expecting this port to be extremely accurate to the SNES original.
switchblade is offline  
Old 07 January 2016, 00:57   #83
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,327
Quote:
Originally Posted by Mrs Beanbag View Post
There exists, for instance, AMOS and Blitz, which have exactly the required APIs already programmed into them, sadly you need to write your programs in AMOS or Blitz in order to actually use them. In fact they are real kitchen sink projects that are as impressive in their comprehensiveness as they are frustrating in their closedness. It must have been far more work to write AMOS or Blitz than just to write a game functions library that could be used from C.
Hey, the hooks and calling conventions of Blitz libraries is documented. Perhaps an able C/asm programmer should just make the appropriate wrapper header files to call those libraries.

Quote:
Originally Posted by Mrs Beanbag
Come on now, C is nothing like asm, the only difficult thing about it is pointers, but once you get your head around that it's plain sailing. It abstracts away the CPU architecture, registers, the stack, &c... I'd say it was more like Blitz with a different syntax. Afterall, arithmetic expressions are almost exactly the same, one just writes such things as "A=(B+C)*D", it even uses some of the same keywords as Basic, like "if" and "else" and "for" and "while".
Well, even something as simple as the C equivalent of the Input command requires usage of pointers (or addresses), as does string and array handling. It's powerful, but it's not nearly as easy as Basic. And at least I find that C is easier to comprehend coming from assembly land than if you come from the real high-level languages.

Note, though, that I specifically wrote that C is assembly language if you don't have the rich support libraries of AMOS or Blitz and can't afford going the (less than simple) OS-friendly route. You'll be banging the hardware directly, just as any assembly programmer. Your 3d routines might be easier to read, but not your sprite or screen setup routines.

Quote:
Originally Posted by Mrs Beanbag
The disadvantage of C over Blitz, apart from performance (which i can't vouch for), is the lack of immediately accessible development environment. Although it binds you to a particular editor which i've heard is not very good, at least you don't have to mess around with command line tools and linkers, it's all self-contained, you just click "run" and it runs.
You bet that TED and SuperTED aren't good editors. They're really hideous, even. I think PED in AmiBlitz improves on it somewhat, but it's still far from what you expect of a proper editor such as TurboText or AMOS's built-in one.

Quote:
Originally Posted by Mrs Beanbag
(Does Blitz have immediate mode? This is also nice for trying things out ad hoc.)
Sadly not. Blitz is a compiled language.

Quote:
Originally Posted by Mrs Beanbag
The limit is not just the performance, it is the lack of structure, flexibility and expressive power.
I suppose C's terseness is what some call expressive, but I don't see how C would be any more structured than Blitz2. Both are structured languages in the classical Algol school. There are some things you can do in C that aren't as obvious in Blitz, but the big picture is very similar. And there certainly are things you can do in Blitz that you can't do in C.
idrougge is offline  
Old 07 January 2016, 01:51   #84
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,393
Send a message via MSN to dlfrsilver
Quote:
Originally Posted by switchblade View Post
You do realize that's not really a valid comparison? As impressive as the Copper is, it's abilities can easily be outmatched through an arcade machine's raw, processing power.

Granted, the arcade's raw processing power wouldn't be as efficient as properly utilizing the Amiga's Copper for certain graphical effects. But then again, most arcade coin-op games aren't really "professionally programmed" like certain Amiga games, if you know what I mean.
the CPUs in coin-op are used to drive the game code, which is not game code like what you'd think for the Amiga or the ST, but an operating system, dedicated to the game on board.

The CPU never see the GFX data, it only communicates with the Video Display chip, which is at least 4 times faster than it (for the CPS-1 for example).

When the CPS-1 VDP is busy display the sprites and moving them, the CPU on its side is taking care of the game logic every 1/60 of sec.

No coin-op CPU is used to move graphics or do any operation related to them. The CPU is only used to drive the board.

You have an over powered 10mhz 68000 just to send data to the chip lol, you talk about a RAW power need .

It's underused, the chipset onboard is doing all the work ! and since the chips are very fast, the 68000 gets the hand back very efficiently
dlfrsilver is offline  
Old 07 January 2016, 09:01   #85
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 303
I have just begun to research this whole Copper thing in more depth, which in my case means the Wikipedia.

Listen everyone, according to Wikipedia:

Uses of the copper

- The copper is most commonly used to set and reset the video hardware registers at the beginning of each frame.
- It can be used to change video settings mid-frame. This allows the Amiga to change video configuration, including resolution, between scanlines. This allows the Amiga to display different horizontal resolutions, different colour depths, and entirely different frame buffers on the same screen. The AmigaOS graphical user interface allows two or more programs to operate at different resolutions in different buffers, while all are visible on the screen simultaneously. A paint program might use this feature to allow users to draw directly on a low resolution Hold And Modify screen, while offering a high resolution toolbar at the top or bottom of the screen.
- The copper can also change colour registers mid-frame, creating the "raster bars" effect seen commonly in Amiga games. The copper can go further than this and change the background colour often enough to make a blocky graphics display without using any bitmap graphics at all.
- The copper allows "re-use" of sprites; after a sprite has been drawn at its programmed location, the copper can then immediately move it to a new location and it will be drawn again, even on the same scanline.
- The copper can trigger an interrupt when the video beam reaches a precise location on the display. This is useful for synchronizing the CPU to the video beam.
- The copper can also be used to program and operate the blitter. This allows blitter operation and control to proceed independently of, and concurrently with, the CPU.
- The copper can be used to produce "sliced HAM", or S-HAM,[1] this consists of building a copper list that switches the palette on every scanline, improving the choice of base colours in Hold And Modify mode graphics.

https://en.wikipedia.org/wiki/Original_Chip_Set#Copper

Especially that sprite re-using feature is potentially insanely powerful...I'm just thinking here that the most advanced Commodore 64 games that had like a 30+ sprites on the screen at the same time, used this techique; they changed the sprite positions mid-frame in order to re-use the 8 sprites that the C64 had. But this spent quite a lot of CPU power if I have understood correctly, and so there was a limit to this.

But here on the Amiga we actually have a specialized chip to do that sort of sprite multiplication thing. Surely we should take advantage of this to the maximum extent possible, and even design our games to use ONLY hardware sprites, and put as much of them to the screen as possible before resorting to bobs. It'll be harder to program of course, but as I mentioned, on the Commodore 64 replicating the sprites like this was considered normal practice, and almost all good action games did that.

Are there any examples of Amiga games which would use only hardware sprites and put huge amounts of them to the screen? And what would be the theoretical maximum amount of hardware sprites on screen on an actual running game?

And also can sprite colors too be changed mid-frame? And if so, could we use this to get an almost unlimited amount of colors for our games? For example could we have 100 copper generated sprites on screen, each with an unique palette?

---

Also here is interesting info about Neo Geo:
https://en.wikipedia.org/wiki/Neo_Ge...hnical_details
As you can see, CPU-wise it's very close to the Amiga, 68000 at 12mhz. And just like the Amiga, for all the awesomeness it relies on a special chipset.

From the wiki article:
" Unlike most other video game consoles of its time, the Neo Geo does not use scrolling tilemap background layers. Instead, it has a single non-scrolling tilemap layer called the fix layer, while any scrolling layers rely exclusively on drawing sprites to create the scrolling backgrounds (like the Sega Y Board). By laying multiple sprites side by side, the system can simulate a tilemap background layer. "

Could we use this same technique on the Amiga? No tilemaps/bitmaps, only Copper generated sprites to create both scrolling and all game objects? And if possible, would it bring any speed benefits compared to bitmap/tilemap scrolling?

---

And for those who are interested, here is a list of various arcade boards from different manufacturers:
https://en.wikipedia.org/wiki/Arcade_system_board
If you check out almost any board that came out in the years 86/87, you'll find lots of hardware with specs close to the Amiga. And in fact in many cases the Amiga hardware is superior.
Master484 is offline  
Old 07 January 2016, 09:54   #86
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 157
Quote:
Originally Posted by Master484 View Post
And even when newer arcade machine generations such as Neo Geo and CPS-1 arrived, the basic A500 could still hold it's own even against them...the only real advantage that the coin-ops had was that they could quickly access their massive arcade cabinet ROM data storges and this way keep up loading and throwing big graphics into the screen at will witout any loading breaks.
Sorry but I have to disagree. Just adding more ROM/RAM wouldn't make a difference on what's possible on the Amiga. It would be still far away from the advantages of a tile based sprite/layer system which almost every (japanese) arcade machine of that era had. And honestly, a comparison with the Neo Geo is ridiculous.
AnimaInCorpore is offline  
Old 07 January 2016, 10:31   #87
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 157
Quote:
Originally Posted by Master484 View Post
From the wiki article:
" Unlike most other video game consoles of its time, the Neo Geo does not use scrolling tilemap background layers. Instead, it has a single non-scrolling tilemap layer called the fix layer, while any scrolling layers rely exclusively on drawing sprites to create the scrolling backgrounds (like the Sega Y Board). By laying multiple sprites side by side, the system can simulate a tilemap background layer. "

Could we use this same technique on the Amiga? No tilemaps/bitmaps, only Copper generated sprites to create both scrolling and all game objects? And if possible, would it bring any speed benefits compared to bitmap/tilemap scrolling?
Just a question: how would you do that having only 8 sprites with 3 colours each - compared to 384 sprites (which are actually vertical strips like the Amiga sprites but those are comprised of up to 32 16x16 pixel tiles having their own 15 colour palette reference).
AnimaInCorpore is offline  
Old 07 January 2016, 11:12   #88
john1979
Registered User
john1979's Avatar
 
Join Date: Jun 2012
Location: UK
Age: 38
Posts: 747
Quote:
Originally Posted by Shatterhand View Post
Super Aleste is full of slowdowns. It's not as bad as Super R-Type or Gradius III, but they are there.

And I don't rememeber ever seen anything on SNES pushing a shitload of stuff on screen like Gunstar Heroes, Alien Soldier, Contra Hard Corps or Vectorman.

A lot of SNES games have slowdown with very few stuff moving on screen. I don't know why it happens, but it does, and it happens a lot more than on Mega-Drive games (even though, yeah, MD games do have slowdowns too, obviously)
The last time I played through Super Aleste I didn't notice much slowdown at all. I'd have to play through it again to be sure, but I think there's less than you say in that game.

I'd agree with the general point that MD games have much less slow down overall, due to the different architecture of the machine (not just the CPU).
john1979 is offline  
Old 07 January 2016, 13:38   #89
Shatterhand
Warhasneverbeensomuchfun

Shatterhand's Avatar
 
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 35
Posts: 2,802
Quote:
The last time I played through Super Aleste I didn't notice much slowdown at all.
Maybe I'm thinking about the original Aleste, which was almost in an constant slowdown, he he he

Quote:
Are there any examples of Amiga games which would use only hardware sprites and put huge amounts of them to the screen? And what would be the theoretical maximum amount of hardware sprites on screen on an actual running game?

And also can sprite colors too be changed mid-frame? And if so, could we use this to get an almost unlimited amount of colors for our games? For example could we have 100 copper generated sprites on screen, each with an unique palette?
Swiv and Hybris are 2 games which, at least I've been told, abuse the Hardware Sprite limit on Amiga.

I am not the most technical guy around here, but AFAIK even though you can change colors midframe, you can't select different colors at different points every frame, you just keep a list of at what point of the screen the color registers will change every frame... you can't have a different list every frame. When you use the copper to change colors on the scanline, you usually do it on stuff that won't scroll vertically, or else you'll see stuff changing colors in the middle of the game. For example, take a look at Lionheart or Shadow of the Beast.. on the 1st level of both games the backgrounds never scroll vertically because their colors are changed midframe by the copper. If they moved vertically, stuff would change color while moving.

So I believe this has not much use for Megaman X, unless you go for a Dual Playfield mode and make the background scroll only vertically, while you'll have just 1+7 colors for foreground+enemy bobs.

Or you can call a Spectrum Day and have stuff changing colors everywhere. That's how we used to play our speccy games

Last edited by Shatterhand; 07 January 2016 at 17:43.
Shatterhand is online now  
Old 07 January 2016, 14:53   #90
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,327
Quote:
Originally Posted by Master484 View Post
I have just begun to research this whole Copper thing in more depth, which in my case means the Wikipedia.
You're putting the horse before the carriage. Make a working skeleton before worrying about deep implementation details.
idrougge is offline  
Old 07 January 2016, 15:38   #91
Raislin77it
Zone Friend
Raislin77it's Avatar
 
Join Date: Jan 2005
Location: italy
Age: 40
Posts: 220
Quote:
Originally Posted by idrougge View Post
You're putting the horse before the carriage. Make a working skeleton before worrying about deep implementation details.
here we are

i've made a small demo in the zone
coded in blitz, just something to brainstorm the community.

the demo isn't optimized, all you watch on screen is blitter "pasted" into the screen, no asm or sprites are harmed in the demo

it was created just for fun. (and because i have a broken hand, so some free time)

ah! i'm not offering to do a conversion , it's just to have a proof of concept (i don't know if works on real amigas, tested only on winuae with ton of mega of ram )


ah! strange enough for me works only with "boot without startup sequence", not from wb
left mice button to quit

Last edited by Raislin77it; 07 January 2016 at 15:43. Reason: damn english !!
Raislin77it is offline  
Old 07 January 2016, 16:03   #92
trydowave
Registered User
trydowave's Avatar
 
Join Date: Jan 2010
Location: Watford UK
Posts: 742
how do you run it? using Winaue and just clicked on the icon. Program failed error
trydowave is offline  
Old 07 January 2016, 16:07   #93
Raislin77it
Zone Friend
Raislin77it's Avatar
 
Join Date: Jan 2005
Location: italy
Age: 40
Posts: 220
Quote:
Originally Posted by trydowave View Post
how do you run it? using Winaue and just clicked on the icon. Program failed error
yeah, boot with no startup sequence.

the problem is the sources are a mess of spaghetti-code,but if noone can start it i will provide the sources.

here works from a 1200 config without startup

i've sayed is a just for fun demo ?
Raislin77it is offline  
Old 07 January 2016, 16:13   #94
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,327
Works with startup-sequence here, from the shell. Perhaps you forgot to include the necessary commands to support start from Workbench?
idrougge is offline  
Old 07 January 2016, 17:29   #95
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 303
My BlitzPlus prototype too has reached a semi-playable stage, the file is in the attachment, and source code is included.

It's still a very much a "work in progress"; I haven't yet done the walls properly, and there are some small bugs which will be fixed later.

But you can already run, dash, jump, shoot while doing any of those, and also the dash+jump works OK.

And you can press some keys on the keyboard to create an infinite number of enemies. But I haven't yet finished the collision routines, so you can't hit or destroy anything yet.

Controls:
Arrow Keys or "A" "S" "D" "W" to move and Space to shoot.
Special keys:
"U" will teleport the player into the top part of the screen.
Pressing "M" "N" and "B" will create enemies to the screen. "N" and "M" create one enemy at a time, but holding down "B" will create 2 enemies every frame, so at 50fps it'll make 100 enemies per second.
And pressing ESC will close the program. The close button of the program window doesn't work.
Also gamepads are supported if you one set up on your PC.

Notice that in most PCs when pressing many arrow keys at once Windows often refuses to register additional keypresses. So pressing down and right to dash may cause the Space bar to stop working, and so on.

But the ASDW keys + Space seems to work better, and also any Gamepad should work, if you have one plugged into your PC (reads only button only).

And the "ExtraAmigaIFFs" folder contains some extra IFF sprites that weren't included in the 2 previous sets that I uploaded, such as the "charge lights" and some "wall kick" frames.

---

And also because this is a BlitzPlus program, it relies on some old DirectX modules to work. When running it in Win 7 or Win 8, if you don't already have DirectPlay installed on your PC, you may see a Windows message that asks something like "do you want to install DirectPlay?". Just click Yes and Windows will automatically install it. Clicking No will cause the program not working. DirectPlay is an old and obsolete DirectX module, that handles things like internet functions. And even if the BlitzPlus program itself doesn't even use any internet commands, it still needs DirectPlay in order to start. And also I have no idea whether BlitzPlus programs work on Win 10 or not.

The final version of this prototype will be complete pretty soon, I'll probably finish it during the weekend.
Attached Files
File Type: zip MegamanXBlitzPlusWIP.zip (542.8 KB, 71 views)
Master484 is offline  
Old 07 January 2016, 17:33   #96
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,327
I'm impressed that both of you can walk the walk and not only talk the talk. Can't test Windows binaries on my Mac, but what's important is that you have a sprite on the screen.
idrougge is offline  
Old 07 January 2016, 22:01   #97
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by idrougge View Post
Hey, the hooks and calling conventions of Blitz libraries is documented. Perhaps an able C/asm programmer should just make the appropriate wrapper header files to call those libraries.
Good idea! It would save a lot of work!

Quote:
Well, even something as simple as the C equivalent of the Input command requires usage of pointers (or addresses), as does string and array handling. It's powerful, but it's not nearly as easy as Basic.
ok fair point, C is so bare bones that doing a lot of simple things can be quite tedious, but that's a question of features rather than syntax. C includes very little functionality on purpose, the idea being, that it is easy to extend by writing libraries. So C with the Blitz library would (maybe? hopefully?) be as fully functional as Blitz.

Quote:
I suppose C's terseness is what some call expressive, but I don't see how C would be any more structured than Blitz2. Both are structured languages in the classical Algol school.
well i'll leave you to it, because i don't know very much about Blitz, my experience is with AMOS and there's a serious lack of structure with that, but, if you don't have pointers, a lot of the more complex data structures become quite difficult to implement. How does Blitz handle memory allocation?

Also i'm used to C++ now so i sometimes forget how many features plain C didn't have.
Mrs Beanbag is offline  
Old 07 January 2016, 22:34   #98
S0ulA55a551n
Registered User
S0ulA55a551n's Avatar
 
Join Date: Nov 2010
Location: Rhondda, Wales
Age: 41
Posts: 490
Interesting tit bit came cross whilst looking at something else. Means mega man does need some extra grunt I think

Cx4[edit]

The Cx4 coprocessor chip in Mega Man X2.
The Cx4 chip is a math coprocessor that was used by Capcom to perform general trigonometric calculations for wireframe effects, sprite positioning and rotation. It is known for its role in mapping and transforming wireframes in Capcom's second and third Mega Man X series games.[2] It is based on the Hitachi HG51B169 DSP.


CX4 wireframe test screen
A Cx4 self-test screen can be accessed by holding the 'B' button on the second controller upon system start-up in both Mega Man X2 and Mega Man X3.[4] In both the PlayStation 2 and Nintendo GameCube versions of Mega Man X Collection, this self-test screen is still accessible in Mega Man X2 (although differently accessed due to the remapped controller configuration), but not in Mega Man X3, because Mega Man X Collection features the 32-bit CD version of the game and not the SNES version.
S0ulA55a551n is offline  
Old 08 January 2016, 04:51   #99
Shatterhand
Warhasneverbeensomuchfun

Shatterhand's Avatar
 
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 35
Posts: 2,802
This is only on Megaman X2 and X3. Megaman X has no extra hardware on the cartridge. I can guarantee you, because it works on my flash cart
Shatterhand is online now  
Old 08 January 2016, 10:45   #100
S0ulA55a551n
Registered User
S0ulA55a551n's Avatar
 
Join Date: Nov 2010
Location: Rhondda, Wales
Age: 41
Posts: 490
Quote:
Originally Posted by Shatterhand View Post
This is only on Megaman X2 and X3. Megaman X has no extra hardware on the cartridge. I can guarantee you, because it works on my flash cart
Sorry my bad

Still interesting. Didn't realise how many different customs SNES chips there were. Only ever really knew of the super FX
S0ulA55a551n is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 03:06.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.09888 seconds with 15 queries