<narimiran>
i'm asking because i'm trying to figure out if it is problem with me, or this is one of the worst programming books i've ever read
badkins has joined #racket
<nisstyre>
narimiran: I haven't read it, but maybe the style isn't aimed at you
<nisstyre>
I thought it was meant for like teenagers or something
<narimiran>
yeah, i'm definitely not a teenager :)
<narimiran>
but that's not a main problem, IMO. the examples are not complete
<narimiran>
some things you can guess, but some others are big mystery (even for experienced programmers), and it makes all your work futile - you're left with a broken game that you cannot run
aidalgol has quit [Read error: Connection reset by peer]
narimiran has quit [Ping timeout: 246 seconds]
ski has joined #racket
sagax has quit [Ping timeout: 260 seconds]
bitmapper has joined #racket
sagax has joined #racket
dddddd has quit [Remote host closed the connection]
srandon111 has quit [Ping timeout: 240 seconds]
srandon111 has joined #racket
badkins has quit [Remote host closed the connection]
badkins has joined #racket
badkins has quit [Ping timeout: 260 seconds]
efm has quit [Ping timeout: 256 seconds]
narimiran has joined #racket
Lowl3v3l has joined #racket
Fare has joined #racket
corpix_ has joined #racket
corpix has quit [Ping timeout: 240 seconds]
badkins has joined #racket
badkins has quit [Ping timeout: 256 seconds]
tlcu_ has joined #racket
jcowan has joined #racket
<jcowan>
Does Racket have a special representation for pointer-to-pair?
<jcowan>
(pre-Chez)
samlamamma has quit [Ping timeout: 244 seconds]
<samth>
jcowan: no
endformationage has joined #racket
<true-grue>
I'm looking for compiler design documents on Chez Scheme. I know about Nanopass papers, but I would like to know more about static analysis and code generation in Chez.
<true-grue>
So, would be thankful for any suggestions :)
<ecraven>
you can always look at the source code
badkins has joined #racket
<true-grue>
ecraven, Thanks. It's not hard to find x86-code generator there. But my goal is to figure out _why_ the code is written in that way. The code is too messy despite the declarated use of powerful eDSLs (Nanopass).
<nisstyre>
narimiran: if you just want to learn Scheme then there are more suitable books for that, and if you want to learn gamedev, there are some great resources I can recommend, but not in Racket
<narimiran>
nisstyre: heh, i wanted something in-between, and that's why i chose that book. for general-lisp stuff, i'm going through SICP. but i'd like to hear your recommendations for both....
ephemeron has left #racket [#racket]
<aeth>
Gamedev is very much a monoculture behind C++ engine with Lua scripting, unless you use a major engine, in which case they each have a different way to script their C++ engine (and none of the major ones you'd use actually use Lua). I guess JavaScript stuff exists, too, because of the browser, but that's sort of a special case.
<aeth>
Now, I mean, none of that is actually *necessary* and you can write a game in anything, but if you do do gamedev in Scheme, expect to manually translate a lot of C-style C++ examples.
<aeth>
"Real" games are far too non-trivial to use as an introduction, though, unless you're scripting someone's high-level engine/framework. There's probably one in Racket. I'm only aware of one in Chicken and one in Guile from the Lisp game jams, though. No matter what, though, it tends to be different from other kinds of programming.
<true-grue>
Looks like there was much easier to write Lisp-game in the past. Because no one knew that it is so hard. So we had at least one quite popular commercial game in 1995 :)
<aeth>
Land of Lisp / Realm of Racket basically just have toy demo games for the purpose of teaching the language.
<aeth>
(at least afaik)
<narimiran>
aeth: i just want to create some very simple games, so my young nephew can (maybe) play them
<narimiran>
aeth: and i don't know if you have seen my earlier (8 hours ago) comment about 'realm of racket'? "i'm trying to figure out if it is problem with me, or this is one of the worst programming books i've ever read"
<true-grue>
I guess the most popular Lisp game of all times was Zork 1. The game is written in Lisp dialect called MDL.
<aeth>
Depends on what you mean by "Lisp game" because some games were scripted in Lisp. Naughty Dog (Crash Bandicoot) used to use something called GOOL, which for some reason Wikipedia decided to put under "Graphics". https://en.wikipedia.org/wiki/Crash_Bandicoot_(video_game)#Graphics
<aeth>
The old AI for AoE II was written in some kind of Lisp-like language with s-expressions, too. I don't know if they kept that when they made the AI much, much better in the rereleases.
sauvin has quit [Read error: Connection reset by peer]
<true-grue>
Yes, both Abuse and more modern Naughty Dog games use Lisp as an embeddable scripting language.
<true-grue>
Zork 1 was written in Lisp, but it's not so impressive achievement, because it's basically the same thing as SHRDLU in Lisp :)
<true-grue>
Anyway, text adventure game is good start, I think. You'll learn strong points of your PL and you will not fight with I/O too much.
<aeth>
I'm not sure any kid is going to be entertained by one. Maybe if you make in the browser.
<nisstyre>
narimiran: for conceptual stuff (not as an implementation guide), handmadehero.org is great. For implementation, I recommend learning raylib.
<nisstyre>
it's cross platform and really well designed
<nisstyre>
for scheme, I recommend the little/seasoned schemer books
<narimiran>
nisstyre: thanks, i'll give it a try tomorrow
<nisstyre>
narimiran: I think the most important thing is to have an idea of what kind of game you want to make, and to make it achievable, but not too easy
<nisstyre>
as with anything
<nisstyre>
and to not try and learn some overly complex tool like Unity or Unreal
<nisstyre>
at least not without being really experienced already
<nisstyre>
I don't think ND ever used Lisp for "scripting" exactly, but as part of their animation pipeline. Originally they had some kind of tool that would try to compress animations down to a smaller size or something
badkins has quit [Remote host closed the connection]
dddddd has joined #racket
badkins has joined #racket
badkins has quit [Ping timeout: 260 seconds]
badkins has joined #racket
orivej has quit [Ping timeout: 258 seconds]
catonano has joined #racket
orivej has joined #racket
<aeth>
nisstyre: eh, Handmade Hero is absolutely not how games are made. I guess the whole "handmade" part implies that.
<samth>
more recently, Naughty Dog used Racket extensively for constructing the game, although it didn't run on the end-user system
<aeth>
Most games use someone else's engine. Of the ones that don't, most use someone else's game framework. Of the ones that don't, most use a portability library like SDL or GLFW. Handmade Hero starts by directly coding to Windows APIs, which is absolutely the worst way to do things if you want a portable game, and you should, since it's easier to write a portable game with SDL+OpenGL than it is to write an unportable game like Handmade (which
<samth>
true-grue: however, if the question is "why does it look like the code was written by a single person who kept everything in his head" then I think the answer is that it was.
<aeth>
The only good thing about Handmade is that any indie game who tries to emulate it by starting with the non-portable Windows APIs is probably never going to be finished, so us Linux gamers will never miss out. :-)
<nisstyre>
aeth: that's why I only suggest it for learning about concepts, e.g. how rendering really works
<aeth>
narimiran: I'd recommend a tutorial that works with SDL+OpenGL, rather than Handmade
<nisstyre>
raylib is how I am suggesting actually building a game
<nisstyre>
there should be lots of tutorials that use it
<aeth>
nisstyre: There is no "how rendering really works". There's "how a rendering API really works" and Handmade takes a very long time to get to OpenGL, where it starts with the absolutely useless "Initializing OpenGL on Windows" (which hard on purpose because Microsoft wants you to use DirectX). Even people writing their own engines will almost certainly use someone else's library for this.
<aeth>
Handmade's definitely not a good starting point...
<aeth>
s/which hard/which is hard/
<nisstyre>
aeth: I cherry pick episodes and find a lot of useful content there
<nisstyre>
but fair enough
<aeth>
I mean, yes, if you're writing your own engine, there's probably some things that you can only find there since, as I said, virtually everyone uses libraries for some of this stuff.
<aeth>
The point is to be ridiculously NIH, after all.
<true-grue>
samth, Thank you! I can't understand why instruction selection phase in Chez is so unreadable. Maybe you have seen examples of instruction selection in ML-family of languages (in Appel book etc). No special tools like Nanopass, but with plain pattern matching you can easily get the code in very declarative and readable style. You can do pattern matching in Racket too. Moreover PLT Redex has most powerful tools for it around. Maybe it makes sense to
<true-grue>
rewrite some parts of Chez core in Racket in a language-oriented programming style?
<aeth>
nisstyre: But ridiculous NIH isn't a good place to *start* imo
<nisstyre>
ok, that's fair
<aeth>
Just write modular code and you can eventually NIH the lower levels. Otherwise you'll never finish. Imo.
<samth>
true-grue: I think the bootstrapping issues make using full Racket unlikely, but pattern matching in scheme is very reasonable. I haven't looked at the instruction selection code.
<samth>
true-grue: note that a lot of dsls are defined there
<samth>
so my guess is that kent prefers that to other possible styles
<dzoe>
Portable graphics engine development?
<dzoe>
:D
<dzoe>
I cannot NOT join this discussion after the last two months.
<dzoe>
It is possible to write a 3D software renderer in pure Racket without relying on any 3rd party libraries.
<true-grue>
samth, Yes, looks like a matter of style.
<dzoe>
It is NOT an easy task, though.
<dzoe>
I really need to finish this project and start releasing the articles and videos.
<dzoe>
Problem is, you need to know a lot of stuff already - not necessarily Racket-related (but that as well).
<samth>
dzoe: i want to read your articles :)
<samth>
also to try your code on Racket CS :)
<dzoe>
samth: actually you made me look into CS a lot
<dzoe>
I hope I can help improving its performance, like I helped futures stability with 3m.
<dzoe>
I assume the boxed flonums will be taken care of by someone eventually, but the rest is ongoing research for me :)
aidalgol has joined #racket
<samth>
dzoe: for boxed flonums: in Matthew's last Racket CS update in Feb, he listed 3 big things still remaining, and 2 of them are now done. boxed flonums was the other.
<dzoe>
Also I easily get distracted and start diving deeper and deeper.
<dzoe>
Lemme show you a screenshot
<samth>
dzoe: also, very few people use futures for real work, so having you do it is especially valuable
<dzoe>
Not the best picture, but all the features are there.
<dzoe>
Transparency, alpha blending, z-buffer and perspective-correct texture mapping.
<dzoe>
samth: I am really looking forward 7.8 release so that I can safely recompile some customers applications. The futures-sort package didn't come out of blue but from a huge project for one customer.
<samth>
dzoe: how does what you're building compare to pict3d?
<samth>
I assume it's a pretty different API
<dzoe>
The graphics project is basically a playground/testground for some of the ideas.
<dzoe>
samth: Well... right now it resembles something like OpenGL actually, but there is no final goal. I am really looking into what is possible and then maybe something will come out of it.
<samth>
sounds fun
<dzoe>
I've spent most of the 90's writing 3D rendering engines :)
<dzoe>
At the moment, the capabilities are more or less on-par with something like Quake 1 engine.
<samth>
the last good video game :)
<dzoe>
Yesterday I added ANSI/UTF-8 driver just for fun (and to test that it is easy to add multiple backend drivers) and hopefully now I can add a Linux fbdev one.
<dzoe>
My sentiments exactly ...
<dzoe>
But apart from being fun, fbdev backend will allow me to test everything on arm/arm64
<dzoe>
And that is my current sub-goal.
<dzoe>
And reading my notes, there is work for years to come :D
<dzoe>
For example, can you imagine futures-based rendering queues which will start the job in the background while being filled? That is what will put the fsemaphores to some hard stress-testing :)
<dzoe>
And of course, lighting is the next graphics thing to go. But I cannot decide which way to go. Simple goraud shading with some perspective correction might be a good test for a start, but really it does not produce super interesting results.
<samth>
dzoe: i think writing some abstractions on top of cas directly may be more useful than using fsemaphores for everything
<dzoe>
But given the current state of affairs, interpolating normals per-pixel won't work in real-time.
<dzoe>
I will do some empirical testing first probably. Some of my expectations were terribly wrong ...
<dzoe>
I like the quite btw, "Programs are what happens between cache misses."
<dzoe>
*quote
<dzoe>
samth: Is there some research into Racket being more CPU-cache friendly?
<samth>
no, not in particular
<dzoe>
Because most of my work will eventually get limited by the memory speed.
<dzoe>
That might be a next step for me.
<samth>
dzoe: my personal feeling is that the key things for making racket more performant are (1) better handling of parallelism and (2) ways of defining data structures that are not all pointers
<dzoe>
I am really considering doing some serious research that can have impact on actual applications.
<dzoe>
"better" is hard to define here.
<dzoe>
For certain workloads, futures are awesome. For others, native threading support might be great - but what about GC, what about locking (with respect to the runtime) etc ...
<samth>
but those are very limited (the docs don't say, but I don't think you should allocate)
<dzoe>
samth: which is very ... manual.
aidalgol has quit [Read error: Connection reset by peer]
<dzoe>
I am pretty sure you should not (reading the call-in-os-thread does not say that explicitly, but basically some limits are there).
<samth>
dzoe: better includes "more lightweight futures" (but also places), some integration between futures and `thread`s, better future scheduling
<samth>
dzoe: but better mostly requires applications that use parallelism
<samth>
for (2), I think something like JavaScript's typed objects would be very valuable (and cache-friendlier)
<dzoe>
samth: Which requires programmers, that can think about writing parallel programs ...
<dzoe>
Well, I think it should be easy to implement typed objects on top of safe C vectors ...
tlcu_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
srandon111 has quit [Ping timeout: 256 seconds]
selimcan has joined #racket
orivej has quit [Ping timeout: 260 seconds]
TCZ has joined #racket
narimiran has quit [Ping timeout: 272 seconds]
srandon111 has joined #racket
vraid has joined #racket
orivej has joined #racket
tlcu_ has joined #racket
rgherdt has quit [Ping timeout: 256 seconds]
true-grue has quit [Read error: Connection reset by peer]
* jcowan
wonders why on all Lisp channels there is always an influx of people who want to (1) learn Lisp via writing a game or (2) want to write a game in Lisp.
<jcowan>
Is it because there are a huge number of people who want to write games, and this is just the subset of them that intersects with Lisp?
<TCZ>
yes
<TCZ>
before people are brainwashed by programming concepts they only want to make games
pilne has joined #racket
<Fare>
when I was a kid, I wanted to write games, too
<pilne>
i still want to write games as an adult, but the kind of game/parts of games i'm interested in has changed somewhat
<Fare>
I wish I could have come up with Baba Is You.
TCZ has quit [Quit: Leaving]
deselby has joined #racket
badkins has quit [Remote host closed the connection]
badkins has joined #racket
Sgeo has joined #racket
badkins has quit [Ping timeout: 260 seconds]
<jcowan>
I wrote a few games as a teen (no computer when I was a kid kid)
<jcowan>
Honest John's Blackjack (which picked a random number when it started up to determine if it should cheat or not
<jcowan>
(however, the banner said "Dishonest John's Blackjack" in that case
<jcowan>
a Star Trek game with ASCII graphics (used up a lot of teletype paper on that one)
TCZ has joined #racket
<aeth>
jcowan: my personal theory is (1) everyone wants to write a game as a side project and (2) everyone wants to learn Lisp as a side project
<aeth>
#lispgames is the same size as #gamedev and is larger than #reddit-gamedev but of course any channel devoted to a specific engine (where most real gamedev is done) is larger than any of those general channels.
<jcowan>
larger = busier, or just more subscibers?
<aeth>
#reddit-gamedev is way more dead than the other two channels.
<aeth>
I guess the demographic has mostly moved to a Discord