I was already a fan of computer + pyramid aesthetics but this one just cuts out the middleman and makes the computer transform into a pyramid.

We should be all caught up after this post. Apologies for any formatting errors. Thanks for reuploading any missing images. I think we’re all set now. ---------------------------------------------------------------------------------- Fellow Time Traveler 07/11/2023 (Tue) 00:00:12 No.3071 (>>3227) >>3079 Open file (2.94 MB 3508x2480f35e389aafba89809aaf68c0e2796d007c80d03fd27a05ee98e8d3d3304aca09.png) Open file (3.58 MB 3508x2480fd7893cab4667184730cc96a2ce364054d54765cef38bb9553d51301106b9362.png) Open file (3.58 MB 3508x248060469e8e4687b84156b22b078831807b7f7966d3f64123ede5c12ab509aae5c6.png) Open file (3.77 MB 4096x187219de6b969dc6b0d4d461142a60cdda171adf34a978f6c02a9edbe48f5ec52fc8.png) These are pretty neat. Fellow Time Traveler 07/11/2023 (Tue) 04:51:22 No.3072 >>3074 >>3070 (>>3222) OpenRA uses the GPL3 license. I know nothing about licenses, but I think that means any project using it legally has to release the source code. >>2888 The artist is having a merch drop on the 14th. https://nitter.lacontrevoie.fr/brawlersworld/status/1679237156462792706 >i plan on doing a full announcement video but just in case i dont get it done in time, here is a quick little post. >july 14th. store will be open for 10 days. pre-order based drop, so no need to worry about anything selling out. >and yes, there is international shipping, but beware! shirts and posters cost a lot to ship! it will be at your expense!!! thank youuuuu I don't normally buy physical merch but I'm considering one or two of the small posters. Fellow Time Traveler 07/13/2023 (Thu) 02:14:20 No.3074 >>3072 More or less; specifically, it means the owner of any project that includes or uses it as part of itself must provide the source code of that project on request, under the same or compatible license. Fellow Time Traveler 07/13/2023 (Thu) 22:24:03 No.3079 >>3080 Open file (226.45 KB 1599x2048絵を描くPETER(エヲカクペーター).jpg) >>3071 (>>3227) Found another. Fellow Time Traveler 07/14/2023 (Fri) 03:30:31 No.3080 >>3083 >>3079 (>>3227) Imagine how many floppies you would need for modern Adobe CS. Fellow Time Traveler 07/14/2023 (Fri) 16:04:01 No.3083 >>3080 It would depend whether they were just good old 3.5 floppies or if they were a new iteration. Floptical drives and media did exist for example as well as others that were pushing the size limitations of common floppies https://en.wikipedia.org/wiki/Floppy_disk_variants

>>3229 Pure bliss... The water and sky are out of this world, and all the colors fit perfectly together. Congrats on another fantastic scene anon! I'm surprised this renders on POV-Ray 2.x, I thought semicolons `;` weren't in use until the 3.x series was released.

>>3234 Wow, thank you so much anon! >I thought semicolons `;` weren't in use until the 3.x series was released. Interesting, mostly I've been using a mix of the 2.x & 3.x docs and it's worked out OK so far.

>>3231 That is really cool Anon. I'd love to have one of those brand-new.

does it look like 2000s anime line up on [AS]

>>3246 https://tofokyo.com I was just about to mention this guy. I absolutely adore the look of the site, and it's very authentic to the 2000s style. The only thing I don't like are the emojis in the page titles but that's a small thing.

If I were going to fix up early POV-Ray 3.x at some point would I be right in thinking that 3.1 is 3.0 but improved? Or are they different enough that they both have merits?

I've written a compilation guide for POV-Ray 2.2 if anyone finds it useful: https://19100.neocities.org/guides/povray2compilation

>>3229 I like the tropical theme. There's something about it for me that feels appropriate for these kinds of old-school renders.

>>3259 Thanks anon. I know what you mean, something about that tropics vibe that just feels right.

Here's some assorted ZX Spectrum artwork AND more importantly the drawing stages that I've been promising to post.

I'll try to post some ZX Gigascreen mode pics tomorrow since I'm way too tired to look at flashing .gifs tonight.

>>3254 Only way to find out is to read the "What's New" doc for 3.1: https://www.povray.org/ftp/pub/povray/Old-Versions/Official-3.1/whatsnew.txt >>3259 CGI water in general was huge in the 1990s and the early 2000s, I'm guessing due to transparency/refraction becoming easier to render or simulate with more powerful hardware. Almost every game I remember from that era had a beach level... Fun times. >>3257 Very informative, thank you anon. I like how clearly you explained the issue with RNG. >>3261 >the drawing stages Interesting... Where did you get those?

>>3265 >Only way to find out is to read the "What's New" doc Can't believe I missed that, thanks! Looks like having 3.0 around will be useful for a couple of deprecated features. >Very informative, thank you anon. Glad that I was able to explain things clearly.

>>3265 I found them on https://zxart.ee/eng/mainpage/ Not every pic has them but at least a few artists are good enough to post their process. Also I mentioned "Gigascreen mode" before as it turns out the moai pic is gigascreen and I didn't realize it. Gigascreen uses both persistence of vision and the latency of a CRT to composite two different graphics together to create colors and patterns that would be normally impossible for the ZX Spectrum. Important note these are going to have flashing images so if you're photosensitive don't click. Because we're all using LCD screens and are probably NTSC these gigascreen demos flash WAY more obviously and dramatically than they would on actual hardware. On a real Speccy with a real 80s TV it would, at most, seem to vibrate subtly. More to follow later since this one doesn't really illustrate the concept as well as it should.

>>3267 More gigascreen pics that hopefully shows the mechanic a little better.

I won't just flood the thread but as you can see the blending can be used to both subtle or dramatic effect. It can smooth out the typical blockieness of ZX art and it can give you some otherwise inaccessible colors.

Just found something interesting, POV-Ray 2's makefiles only specify basic optimization (-O), with -O2 you can get up to around 30 seconds of time saved for longer renders. Resulting files are checksum identical too so no issues there.

>>3273 Good tip, thanks anon.

https://twitter.com/marc_acrylic/status/1688272514995073025 The animation isn't really it for me, but the post production effects present some potential to the pipeline of imitating 80s-90s anime or outsourced animation styles

>>2888 The BrawlersWorld guy made the official music video for a song by a Japanese musician. https://www.youtube.com/watch?v=d7OowNUkT_U Pardon the direct link, but I don't feel like converting it to a smaller filesize right now. It's a neat video but the style isn't really for me.

>>3374 Cool to see Brawler getting work but I'm not feeling the style either, looks too modern I think (also are people really making portrait mode music videos now? WTF).

>>3384 I think its because they lack that pre-rendered look and go instead for the "low-poly/ps1" look

I think I've pretty much reached the practical limits of this old i3. Source: https://archive.org/download/19100-povray/king.zip

>>3409 Beautiful lighting and colors, I've always wanted to make a bowling scene in POV-Ray. Excellent work anon!

>>3409 Looks pretty good, great job there.

>>3410 >>3411 Thanks anons, glad to get it out the door after so much rendering!

>>3409 Looks nice! that timing tho. :^)

>>3413 Oh shit you're right, didn't make the connection until now

Here's a really interesting ZX Spectrum image but I'm not sure if I understand how it exactly works. I've included the conversation below if anyone a Russian speaker. >abelenki09.09.2023 19:08 >hmm - Standard 6912. это как? и что значит палитра Electroscale? >breeze09.09.2023 19:45 >Врубаешь ч/б «Рекорд-312» и ловишь волну :) >abelenki09.09.2023 19:14 >забавно - вот как выглядит без палитры - http://lowtrucks.net/Forums/Pictures/ZXArt-EE-Grongy-BW.png >а как данную палитру (grayscale) можно использовать на реальном железе? >moroz199909.09.2023 19:43 >Потребуется старый черно-белый телевизор, скорее всего. >abelenki09.09.2023 19:58 >ясно. :D кстати, мой первый спекки вроде был Ленинград 48 (отец спаял) + крошечный ч/б телевизор (не помню >модель). и сним была кассета с Saboteur II. >ax3409.09.2023 22:48 >Ручку цветности у реального железа (телевизора кинескопного, например) покрутить. >ax3409.09.2023 21:45 >Можно сделать конверсию в ULA+, например, в оттенках синего/голубого. ax3409.09.2023 21:59 >Edit: >png: https://vk.com/s/v1/doc/QZleES9Tdj9MNq37MYE6XvwHIei4S21gdobyDS9t8UkIHcLX7P4 .scr: https://vk.com/s/v1/doc/iTLpRvtzDTko2wotbu7WIztl0UtPEIa7wklQjmh_STr_w1upmPw /.abelenki09.09.2023 22:03 >классно получилось!

>>3409 Nice neon lighting there. >>3451 That's a ZX Spectrum image? Holy crap.

>>3452 >That's a ZX Spectrum image? Holy crap. Yeah and I'm not really certain how it's done. As far as I can tell it's the only image on the Spectrum site that's tagged with "Electroscale" for the palette type. I'm not sure exactly what that means.

>>3454 Tried running it through DeepL, don't know anything about the Spectrum but it seems to have done a decent job: >abelenki09.09.2023 7:08 pm. >hmm - Standard 6912. is that how? and what does Electroscale palette mean? >breeze09.09.2023 19:45 >Turn on the b/w "Record-312" and catch a wave :) >abelenki09.09.09.2023 19:14 >funny - here's what it looks like without the palette - http://lowtrucks.net/Forums/Pictures/ZXArt-EE-Grongy-BW.png >and how can this palette (grayscale) be used on real hardware? >moroz199909.09.2023 19:43 pm. >It would require an old black and white TV, most likely. >abelenki09.09.09.2023 19:58 >clear. :D btw, my first speckki was a Leningrad 48 (my father soldered it together) + a tiny B&W TV (can't remember the model). and it had a Saboteur II cassette. >ax3409.09.2023 22:48 >Turn the color knob on a real iron (kinescope TV, for example). >ax3409.09.09.2023 21:45 >You can make a conversion to ULA+, for example, in shades of blue/cyan. ax3409.09.2023 21:59. >Edit: >png: https://vk.com/s/v1/doc/QZleES9Tdj9MNq37MYE6XvwHIei4S21gdobyDS9t8UkIHcLX7P4 .scr: https://vk.com/s/v1/doc/iTLpRvtzDTko2wotbu7WIztl0UtPEIa7wklQjmh_STr_w1upmPw /.abelenki09.09.2023 22:03 >classic turned out!

Does Iron Lung count?

This masterpiece: https://youtu.be/phJ3N7OYcqo

Prior to 3.7 POV-Ray couldn't use multiple threads, or could it? https://19100.neocities.org/guides/povraymultiprocessing

>>3545 Good effort anon, however I strongly advise against using `dd` to manipulate images. `dd` is known as "disk destroyer" [1] for a good reason, users writing their first shell scripts should not use it... Image manipulation should be done using ImageMagick (IM) or GraphicsMagick (GM), which are widely available and easy to compile if needed. You can compile GM using nothing but a C compiler, without any libraries, and get a fully working program that manipulates TGA and GIF images. I wrote my own threaded povray script in 2021, and while it's not the cleanest nor the most elegant, I'm sharing it here with the hope that it will be useful to you: https://pastebin.com/eM9DWTyp TL;DR - Set all parameters at the top of the script, only take the POV file as input. - Create a temporary directory and stick to it. - Render the input file into 240x240 chunks, account for fractional chunks. Each rendered chunk contains the cropping information in the filename. - Use up to 16 processes at a time for rendering. Maintain 2 lists: started and finished processes. Infer how many processes are still running by comparing both lists. - Rendered chunks are partial images that cannot be read by IM/GM. Append zeros to the chunks [2] until they become complete images. - Using IM/GM, crop all chunks and stitch them together into the final image. [1] https://www.cloudnull.io/2011/12/dd-and-the-mighty-disk-destroyer-or-duplicator/ [2] To complete a partial image, simply tell POV-Ray to "continue rendering" it, but using a different (empty) scene as input so it renders instantly. The resulting image will contain the rendered chunk at the top while the rest is black.

>>3570 Thanks for the feedback anon. >I strongly advise against using `dd` to manipulate images. Yeah I'm aware of the risks with dd, ImageMagick would've been my first choice but I wanted to keep non-POSIX tools (other than POV-Ray of course) & features to a minimum for portability and unfortunately dd seems to be it for copying bytes around with the standard utils. I'll put a warning in the guide though so people know to be careful. >I wrote my own threaded povray script Nice, it's interesting to see your approach. >"continue rendering" it, but using a different (empty) scene as input so it renders instantly. That's a good trick, I hadn't thought of that!

>>3572 >I wanted to keep non-POSIX tools [...] to a minimum for portability In that case it's better to use `head`, `tail`, and `printf`: # stitch the top half of image1 to the bottom half of image2 (640 x 480) head -c $(( 18 + 460800 )) image1.tga > out.tga tail -c 460800 image2.tga >> out.tga # stitch three 640 x 160 chunks (no padding/margins) into one 640 x 480 image head -c 18 chunk1.tga > out.tga tail -c +19 chunk1.tga | head -c 307200 >> out.tga tail -c +19 chunk2.tga | head -c 307200 >> out.tga tail -c +19 chunk3.tga | head -c 307200 >> out.tga # given a width and height, write a TGA header to a new image W=640 ; H=480 WHI=`printf "%03o" $(( W / 256 ))` # width (high byte) WLO=`printf "%03o" $(( W - (W / 256 * 256) ))` # width (low byte) HHI=`printf "%03o" $(( H / 256 ))` # height (high byte) HLO=`printf "%03o" $(( H - (H / 256 * 256) ))` # height (low byte) HD1="\0000\0000\0002\0000\0000\0000\0000\0000\0000\0000\0000\0000" HD2="\0030\0040" printf "%b" "$HD1\0$WLO\0$WHI\0$HLO\0$HHI$HD2" > out.tga # fill the new image with white i=0 while [ $i -lt $(( W * H )) ]; do printf "%b" "\0377\0377\0377" >> out.tga i=$(( i + 1 )) done

>>3577 Whoa thanks, I reworked things to remove dd. The only limitation was that -c isn't part of POSIX head (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/head.html ) but split can be used as a workaround.

>>3579 >The only limitation was that -c isn't part of POSIX head >split can be used as a workaround Good catch, I didn't think they'd add -c to `tail` but not `head`... I did some digging and found this tool as well: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/od.html `od` splits binary files with great flexibility and outputs hex/octal format strings, which are then converted back to binary using `printf`. The only issue is that `printf` is quite slow, so only use it if `split`/`tail` aren't cutting it: # binary cut ($1 = input file, $2... = od args) bcut () { F1="$1"; shift; od -vAn -to1 $@ "$F1" | while read l; do for b in $l; do printf "%b" "\0$b"; done; done; } # write the header of a large image to a new file without splitting bcut image1.tga -N 18 > image2.tga Also worth considering is `xxd`, which is part of Vim. The entire program is in a single MIT-licensed C file: https://github.com/vim/vim/raw/master/src/xxd/xxd.c `xxd` operates almost exactly like `od` except it only uses the hex format, and is pretty darn fast. It can also be used to implement a "binary sed" that replaces arbitrary byte sequences in files.

>>3588 >Good catch, I didn't think they'd add -c to `tail` but not `head`... Some of the omissions in POSIX are really weird, it's easy to see why GNU et al. made so many extensions. >The only issue is that `printf` is quite slow That's too bad, still good to know though. >Also worth considering is `xxd` Oh yeah I've used it before for doing hex-to-binary conversions, very useful tool.

>>3545 >>3570 >>3572 >>3577 >>3579 >>3588 >>3589 Severe case of outside looking in here, but what can you use all this for? And can it still be used?

>>3590 Hey anon, all of that stuff is about finding different ways to combine pieces of an image from the command-line, like a jigsaw puzzle. Old versions of the POV-Ray ray tracer don't take advantage of modern multi-core processors, which means rendering a scene can take much longer than it has to. For example, >>3409 took over 8 hours to complete. The solution is to run POV-Ray multiple times simultaneously, with each program rendering only a fraction of the scene. Each part of the image is a separate file though, so you need to stitch them together to get the final render. If you're interested in learning more, >>2203 is a good place to start.