Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 18:14 25 Apr 2024 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : Seeking Games Programmers

     Page 9 of 9    
Author Message
Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9060
Posted: 08:49am 06 Apr 2019
Copy link to clipboard 
Print this post

  Turbo46 said   I’ve been reading through this post again while waiting expectantly for the revised CMM firmware and would like to make a few observations.


......

2. Sound has been mentioned but nothing conclusive has come out of it. I would like to see provision for an external sound chip. Perhaps similar to MauroXavier’s efforts or perhaps a PIC32MX170 could be programmed to act as a sound chip.


Perhaps the YM3812 by Yamaha?
They are about one buck a piece at the moment, and are very easy to find.

LINK.

Demo Video Of The Sound.

This may perhaps, be beyond what the new MM design can perhaps do in terms of its ability to stream 8-bit parallel data to this sound chip, but it sounds great and is only one buck a chip....
Smoke makes things work. When the smoke gets out, it stops!
 
CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 1985
Posted: 01:53pm 06 Apr 2019
Copy link to clipboard 
Print this post

That yamaha chip was legendary for the classic arcade sound... two of them and a dedicated Z80 @4MHz did this with Konami's sound team and the rather oddly named Metal Yukhi in charge.

Computer generated sounds today are mainly a procession of samples... proper raw sounds generated by chips directly are rare.

I am blessed to have been able to spend my youth/formative years adorned by arcades with this effort. Strange I have fond memories but absolutely zero desire to play computer games now-a-daysEdited by CaptainBoing 2019-04-08
 
ceptimus
Senior Member

Joined: 05/07/2019
Location: United Kingdom
Posts: 130
Posted: 07:27pm 13 Aug 2019
Copy link to clipboard 
Print this post

Oops. I should have read the manual before posting. I was suggesting an 'overlap' test as an alternative to a 'touching' test for sprite collisions, but now I see that Geoff was (as usual) miles ahead of me, and already has that covered.

So I'm editing this post as I don't think I can just delete it.
Edited 2019-08-14 05:47 by ceptimus
 
Poppy

Guru

Joined: 25/07/2019
Location: Germany
Posts: 486
Posted: 08:52pm 13 Aug 2019
Copy link to clipboard 
Print this post

  Grogster said  
  Turbo46 said   I’ve been reading through this post again while waiting expectantly for the revised CMM firmware and would like to make a few observations.


......

2. Sound has been mentioned but nothing conclusive has come out of it. I would like to see provision for an external sound chip. Perhaps similar to MauroXavier’s efforts or perhaps a PIC32MX170 could be programmed to act as a sound chip.


Perhaps the YM3812 by Yamaha?
They are about one buck a piece at the moment, and are very easy to find.

LINK.

Demo Video Of The Sound.

This may perhaps, be beyond what the new MM design can perhaps do in terms of its ability to stream 8-bit parallel data to this sound chip, but it sounds great and is only one buck a chip....

Just leaving the topic a bit further, but what this Guy is doing concerning sound is really great:

https://www.aidanlawrence.com/
-> Electronics
-> 2017
-> 2018 (-> Adlib Mini)
-> 2019


Andre ... such a GURU?
 
ceptimus
Senior Member

Joined: 05/07/2019
Location: United Kingdom
Posts: 130
Posted: 09:03am 22 Aug 2019
Copy link to clipboard 
Print this post

A way of saving part of the screen to an off-screen buffer would be useful. One way it could be implemented that should be fairly straightforward would be a Sprite GRAB command that would copy a 16*16 pixel area of screen to a sprite, overwriting the current sprite contents.  The GRAB parameters could optionally include a colour that would become the sprite's transparent colour.

Sprite GRAB 3,100,120,0 would copy the screen (100,120)-(115,135) into sprite 3, using black (0) pixels on-screen as the sprite's new transparent colour.  If the last parameter were omitted, the sprite would have no transparency.

If in future versions, a sprite can be a different size than 16*16 pixels, then the defined size of the chosen sprite would control how much screen were captured.

I know we can do something like this at the moment, using the pixel() function and pixel command or by  Peek()-ing and Poke-ing the video buffers, but both those approaches are too slow and awkward for fast-paced games.

Another way would be to allow the blit command to blit to and from an invisible off-screen buffer, but that would either waste memory by having a fixed buffer size, or would need some new commands to allow a program to specify and reserve an area of memory for the off-screen buffer.  I suppose if blit could work to and from the memory in an array, then we could just use Dim to reserve the required memory?
Edited 2019-08-22 19:05 by ceptimus
 
hitsware2

Guru

Joined: 03/08/2019
Location: United States
Posts: 705
Posted: 02:02am 24 Aug 2019
Copy link to clipboard 
Print this post

Need serial out @ 31250 .....
my site
 
     Page 9 of 9    
Print this page


To reply to this topic, you need to log in.

© JAQ Software 2024