 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 : PicoMiteVGA: Framework for ray casting using the DDA method
  Page 5 of 6   |
|||||
| Author | Message | ||||
Martin H. Guru  Joined: 04/06/2022 Location: GermanyPosts: 1422 |
Back to the old concept. Just one small change: ‘added view bobbing’, i.e. slight camera shake to simulate the steps. cast088.zip 'no comment |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5777 |
@Martin, Thanks to your hint yesterday, I spend the evening on PicoTrek. It is finally comming together. Expect a beta release in few weeks (I feel I'm 80% there, but trust the 20/80 rule). I will try your cast088 on a pico RP2040 today. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1422 |
I have sent you a download link for my entire Colossal Adventure folder as a private message. Perhaps you can make something of it. 'no comment |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11054 |
I have reviewed the possibility of including IMAGE RESIZE in the PicoMite and the answer is no. None of the CMM2 code is transportable and although the algoritm is easy enough implementing it for 1-bit, 4-bit, 8-bit, 15-bit, 16-bit and 24-bit output devices is a lot of work and would add a huge amount of code. This could not be included in the RP2040 at all without reducing the A: drive too much and the use on the RP2350 would be pretty limited. There is a readpixel, writepixel abstraction that could be used but would be too slow to be usable. Edited 2026-03-04 20:09 by matherp |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1422 |
Thanks Peter for trying, The scalable Blit or Sprite would have provided a ‘poor mans Sega Superscaler’ as a tool. So I'll stick with the filled blocks for now, especially since it's going much faster than expected. Cheers, Martin Edited 2026-03-04 20:49 by Martin H. 'no comment |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4360 |
Hi Peter, One attempt to persuade you otherwise. I imagine the most likely usage for a "native" image scaling facility would be for "performance" graphics applications, i.e. games and they will almost all be using the 4-bit graphics so why not just implement it for that colour-depth? I would argue it would be a much more generally useful facility than say for example a native raycaster  .Note that using it to scale "sprites" is the more likely use-case. Martin's potential usage is literally just a (vertical) edge-case. Best wishes, Tom Edited 2026-03-04 21:59 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11054 |
You mean like this God, I'm good to you lot  |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8667 |
lol! Indeed you are. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4360 |
Thanks Peter. I should probably have kept my mouth shut since now I'll need to implement it for MMB4L; which already had IMAGE RESIZE_FAST but none of the other IMAGE sub-commands. You should probably add a parameter to specify the transparent colour. You may be asked whether it should also have the "mirror flags" ... however if your BLIT code is anything like that which I wrote for MMB4L then you might think you'd rather dig your heart out with a blunt spoon (EDIT: I suppose you could compromise and always go through a temporary surface in that case and do it in two steps). Note that unless I am mistaken there is a historical inconsistency in the BLIT commands in that many of them allow you to specify a transparent colour, but it looks like BLIT WRITE does not, does it assume black? or inherit it from SPRITE SET TRANSPARENT from back when BLIT and SPRITE were the same commands ? - either way it doesn't appear to be documented. Best wishes, Tom Edited 2026-03-05 00:50 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
LeoNicolas Guru Joined: 07/10/2020 Location: CanadaPosts: 565 |
What is the difference between BLIT RESIZE and IMAGE RESIZE? Is the blit resize available on the CMM2 firmware? The CMM2 firmware is a little behind on updates and new commands. Will we have new updates? I'm asking this to understand which is the future of the platform, and maybe to move my development entirely to the pico Edited 2026-03-05 01:44 by LeoNicolas |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11054 |
Tom I don't think transparency makes any sense. Is it for the source or destination? In either case you will get strange artefacts with transparent pixels missing or not depending on the ordering in the algorithm |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4360 |
Consider the Pole Position case, you've got the "sprite" of an opposing car that you want to scale depending on how far into the distance it is, so you want to specify what colour on the original sprite is transparent and have that respected when it is scaled and blit. I can't comment on the artefacts without a specific "this looks wrong" example. EDIT: Note I don't know how/if any of this should also have implications for SPRITE ... part of me wishes MMBasic didn't have any SPRITE support at all, but instead provided lower-level routines to determine whether two boxes, circles or other primitives had intersected ... I may be deluded in this wish. Best wishes, Tom Edited 2026-03-05 02:25 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1422 |
Hi Leo The IMAGE Command is much more powerfull with its options RESIZE RESIZE_FAST ROTATE ROTATE_FAST IMAGE WARP_HV If I understand correctly,with BLIT RESIZE Peter has basically only implemented IMAGE RESIZE_FAST for the Pico, i.e. only the nearest neighbour and only for RGB121. I will install the firmware update tomorrow, then I will see what happens. Cheers Martin 'no comment |
||||
| dddns Guru Joined: 20/09/2024 Location: GermanyPosts: 794 |
That feature looks nice and realistic. It runs fast and now on the latest RC1 the ILI9341buff driver works, many thanks! The timer value does not exceed 60. Best success! |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1422 |
Okay, this is a first attempt at implementation with the new BLIT RESIZE feature. It only works with the latest firmware update (PicoMite V6.02.01 release candidate) and, for now, only on Pico.  ccast1.zip This is a quick integration of the new function/command. Just to see the difference. As a reminder, 11 FPS * 120 calls = 1,320 BLITs per second(not including the whole Raycast calculations..) The adjustment for MMB4W/CMM2 via Image Resize will come later. Enjoy testing it out! Martin Edited 2026-03-05 22:55 by Martin H. 'no comment |
||||
homa Guru Joined: 05/11/2021 Location: GermanyPosts: 548 |
WOW WOW WOW Martin, I am more than impressed. Thanks also to Peter ;-) It runs quite well on my HDMI USB Pico2. Not necessarily for a shooter, but for a 3D maze or role-playing game, it works really well. And who knows what other optimisations there are... I'll take a look at the code over the weekend. This week is far too busy at work. Matthias |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 769 |
Hi Martin, I have tried out your latest ccast1 program from above on 480x320 LCD ST7796S, 2350 running at 420MHz. All I had to do was remove the Mode 2, everything then just worked, full screen. At this resolution I'm getting around 10 to 11 fps. If I limit the screen size to 320x240 (using Poke Display Hres 320 & Poke Display Vres 240) I'm seeing an update rate of about 18 to 20fps. Not Bad! :-) but may not leave much spare for other processing :-( If I limit the CPU to 252MHz I get around 6 to 7fps and 10 to 12fps respectivly. Regards Kevin. |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1422 |
Kevin, if you use 480x320 the Programm uses 360x240, so it has to do 180 Blits per Frame. Of course this takes longer, but the graphics are also nicer.You compensate for that with the higher clock speed (430 vs 252). For some reason, I can't get my Pico2 above 252 at the moment (or maybe I'm just too stupid). And yes, you're right, in the current state, there's no CPU time left here for other calculations such as game logic or similar. On the other hand, when I think back to my first attempts at ray casting a few years ago (with Pythagoras), this is with DDL already a quantum leap. . I think we have to find a middle ground here, using texture mapping or box commands, depending on what you want to programme, (or we can think of other tricks to save CPU time). Cheers Martin Edited 2026-03-06 03:41 by Martin H. 'no comment |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1422 |
Fortunately, I had the opportunity to retire since January 2025. Due to various health problems, I was allowed to leave three years early. But I still work on an hourly basis, as no suitable replacement has been found yet. It's nice to see others searching for Ideas to use the code for their programmes, that's what it's intended for. Cheers Martin 'no comment |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 769 |
Hi Martin, I don't know much about this type of perspective graphics, but would some combination of what you have done & the Ray casting primitives that Peter has put in be able to speed up what you are doing? It's a very interesting thread anyway, especially the DDA aspect & how that works. Regards Kevin. |
||||
| Page 5 of 6 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |
