 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 : Introducing the Colour Maximite 2
  Page 13 of 25   |
|||||
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9493 |
Yeah, exactly. We all have spent a HEAP of time on this development, and matherp has spent MONTHS of coding on this release......to have someone come along IN THEIR VERY FIRST POST and suggest they could have done things better......sorry, Gizmo, but phuck.... Smoke makes things work. When the smoke gets out, it stops! |
||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 10071 |
I would have been very happy to include CSUB/CFUNCTION support in the CMM2 - it isn't very hard to do. However, the issue is how to create the CFUNCTION in the first place. Someone would need to work out how to configure STM32CubeIDE to produce elf files with the appropriate characteristics (position independent code etc.) and someone would need to write an equivalent of CFGEN for ARM elf files. Neither of these activities is anything I have any intention of tackling. |
||||
| Raul Newbie  Joined: 06/05/2020 Location: United KingdomPosts: 11 |
WOW! What's up your bum? Obvious confirmation of inferiority complex. |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1636 |
I don't wish to write a sprite editor and CMM1 sprites are easy enough to create. But now, with the CMM2, there are new ways to create sprites within a program but no way to save them. I understand that that they can all be created externally but it seems to me that, having created them within the CMM2 that you should be able to save them as a sprite file to avoid having to create them again as you need them in a program. A sprite must exist in memory as some block of information, even a CMM1 text file one so, I thought it could be saved? Just an observation from someone who is NOT a games programmer. Bill Keep safe. Live long and prosper. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10071 |
Sorry but I don't understand what need you think is there that we are missing. Sprites are already saved in that you read them in from a PNG or a text file or you can cut them from another image on a background page. The overhead of this is very small so there is no advantage that I can see to defining some new binary format which would be a "saved" sprite file. In a perfect world there may be a case for writing out a sprite as a png file but writing png files would need a lot of extra code adding to the firmware. As I said previously, I will look at adding a selective save capability to IMAGE SAVE. Then the only thing needed would be to load the resulting bmp file and then use SPRITE READ |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4251 |
I suspect this isn't his first post, just his first post under that name. MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4251 |
Since I believe Peek allows you to read data from the screen memory (and even that may not be necessary) then unless I am missing something it should be possible to write a Sprite Editor in BASIC that generates .png files. Best wishes, Tom Edited 2020-05-17 21:36 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4251 |
In passing, and this might be the wrong thread: - It looks like the CMM2 is probably fast enough to implement Elite in BASIC. - It's not fast enough to implement an "Another World" VM, it can't push polygons fast enough. However that might be due to the BASIC overhead of calling Polygon and could be resolved by a firmware change to add a specialist Polygon function that was pointed directly at a block of data describing multiple Polygons to render. I AM NOT suggesting Peter should do this, just musing. Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4251 |
Thanks Peter, Then I guess if/when the time comes I'll have to do it myself  Finding the time would be a fine thing; perhaps in 20 years when I retire.Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10071 |
The c source file that just reads PNG files is 1200 lines long - good luck  |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1636 |
OK, thanks, AS I said, just an observation. As I was wondering... Bill Keep safe. Live long and prosper. |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4251 |
Perhaps we have different conceptions of what a lot of code is. I wish I had the time to rise to the challenge  But seriously, the CMM2 - Wow! Massive plaudits to all involved. MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10071 |
Watch this space Have you got a sample list of polygon coordinates you can post for test purposes? Edited 2020-05-18 00:00 by matherp |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4251 |
Sorry Peter. I was just randomly pregenerating 4 sided polygons and seeing how long it would take to draw 10,000 of them. I can post the code but it's nothing you couldn't knock up in 10 minutes. I've just been engaging in some random speculation on the possibilities for future projects if I ever get my Zmachine implementation completed. I haven't looked into the Another World VM in any detail beyond working out for it to be possible you need to be able to render ~1000 polygons at 20 FPS. Ultimately unpacking the vertex data from the byte code into arrays for MMBasic may be as much a bottleneck and require CFunctions to address. Like I said, idle speculation. Regards, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10071 |
Based on a very quick look that isn't how it works. The background polygons are drawn onto 1 video plane and things that move onto another. These are then merged to create the actual moving pictures. So the number of polygons to draw at 20fps is actually quite small. The CMM2 suits this perfectly. The background can be drawn onto one page. Then the moving bits are drawn onto another for each frame. BLIT with the transparency bit set as explained in the tutorial can then do the merge. Nearly all drawing commands on the CMM2 support arrays as input so for example you can put 1000 coordinate pairs into an x array and a y array and then plot all of them as a single PIXEL statement. I have never bothered doing this for polygons as I have always assumed that most games use triangles and the triangle command already supports arrays as input. Check the manual and have a play. Adding arrays of polygons will need a small syntax change but is probably worth doing now rather than later |
||||
| cdeagle Senior Member  Joined: 22/06/2014 Location: United StatesPosts: 265 |
For what it's worth, I plan to test all my number-crunching programs as soon as I have a CMM2 up and running. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4860 |
Hi matherp, You may be able to solve this (prevent high currents with headset plugged in, and drive PWM to digital inputs) bij adding few components. See below. The max DC current is limitted. But the AC output impedance is low.  The electrolitics can be ceramics also. 10uF in 0805 is very common. I am not sure if you need a low pass filter. Haven't build a CMM2, so I am not sure what the frequency spectrum looks like. Regards Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Andrew_G Guru Joined: 18/10/2016 Location: AustraliaPosts: 868 |
Hi All, An amazing effort and I want one NOW! (I guess I have to wait until SC produce their kit - I'm in Melbourne, Aus). I am a little confused (not hard) by the USB B and USB A connectors (CON1 & 2 respectively). In Geoff's Constructor schematic CON1 appears to be the source of power - it has the switch. But elsewhere it is described as a USB keyboard?? CON2 also appears to be a source of 5V (and console TX/RX) - it is labeled "Host". Is there a problem if both CON1 & 2 are connected to 5V from different sources (eg one a PC the other a Wallpack - with different grounds?). I bet that you have considered all angles but is there a case for a 5V coax jack like Geoff uses for the Air Quality Monitor? Labeled "OR" for whichever of CON1 or 2 is power input when not programming etc. (I've now read both of Geoff's manuals - as usual very clear and lots of examples - thanks) Cheers, Andrew |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6221 |
CON 1 is indeed the power input as well as USB-TTL for console use. CON2 is a 'host' for the USB keyboard. The 5V is there to power the Keyboard. It is not a power input You can also use the Keyboard connector and a USB type A Male-Male cable to program the beast. A few seconds compared with 6 minutes if you use the console to update the firmware. In this case, it IS a power input and the power switch would be 'off' if separate power sources are involved. Jim VK7JH MMedit |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4251 |
Thanks Peter, Yes, I knew this, but was planning on a worse case given I also have to do all the other byte code processing in each frame and my Zmachine experience shows that can be quite heavyweight in BASIC. I would still expect to sometimes need to render 100 polygons per frame, which as you indicate should be within the bounds of possibility. Actually that's not how it appears to be done. They have a "background" page and a "compose" page. You first blit the "background" -> "compose" and then draw polygons directly on "compose", no need for transparency. After that you copy "compose" to the display. Sort of ... I think at least in some hardware implementations you can change which buffer the display points at instead of having to blit to the display, and also for performance reasons they keep another page containing the previous background in case the player heads back there. Yes, I saw an earlier comment from you to this effect. I note that in these cases the number of boxes, lines, pixels, triangles is determined by the size of the smallest array. Have you considered performance impact / memory fragmentation issues if these methods need to be called frequently with different array sizes - which have to be allocated each time? Perhaps you could support calling with larger arrays than required, but with a magic value (999?) in the first X coordinate indicating that all successive elements should be ignored. Then the user could just allocate one set of large global arrays and reuse them. I also note that at least for Triangle the 'c' and 'fill' parameters also need to be arrays if the vertex coordinates are, however the documentation "suggests" they could be scalar. I'd certainly appreciate it if you could support this. Best wishes, Tom Edited 2020-05-18 19:46 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Page 13 of 25 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
