|
Post by felixp7 on Oct 6, 2019 19:04:35 GMT 1
Hello, everyone! I'm new here. My story goes like this: discovered BaCon a few years ago, but dismissed it at the time. Having ran into it again in recent weeks, I decided to give it another chance, which went a lot better. It helps to have a number of games in one's portfolio that fit the language well, and can make for good ports to learn from. To begin with, I picked the first game from my Robots in Spring album. Apologies for the shameless plug; this is so you can see what the original is like. It seemed like a poor choice at first, but two days later it's actually complete and working. Didn't test it much though, so there could be bugs. Not to mention this is my first substantial BaCon program, so I'm probably doing a lot of things wrong. Please be patient. Anyway, thanks for having me. Can't wait to hear what you think, and to tackle more games. Cheers! Attachments:10-reverse-robots.bac (9.25 KB)
|
|
|
Post by bigbass on Oct 6, 2019 19:58:53 GMT 1
Hello felixp7 Welcome to the forum I am using the small raspberry pi3 (the hardware is very limited for games) and congratulations it compiles and runs on the RPI3! and all under 400 lines of code is very impressiveI had to comment out one line of code line # 180 "INIT we need this type of fun stuff and an excellent demo game using HUG with the CANVAS! A big thanks and welcome to the forum again Joe
|
|
|
Post by felixp7 on Oct 7, 2019 4:51:10 GMT 1
Thank you very much for the nice words! I did notice that HUG calls INIT at include time, but the Color Lines example on the site calls it again, and that didn't seem to cause a problem for me here. Might be due to how I'm using the latest HUG from the website, but an older BaCon: 3.7.2 from the Puppy Linux SDK. Will leave it out from now on. As for the size, I got lucky with the game design on this one, and making the window fixed size probably helps too.
Thanks again, Back soon with more games.
|
|
|
Post by Pjot on Oct 7, 2019 17:17:46 GMT 1
Thanks felixp7, And again welcome to the BaCon forum The program compiles fine, also in the latest versions of BaCon. Your code looks very clean, and at first glance, there does not seem to be much wrong with it. So a very impressive start for your first program in BaCon! I am looking forward to see more. Best regards Peter
|
|
|
Post by felixp7 on Oct 8, 2019 16:52:40 GMT 1
Thank you very much for the warm welcome! I'm back as promised then, with the second game of the series. Got a couple of questions this time to go with it: - I notice BaCon compiles = to == in e.g. the condition of an IF, but not in a RETURN expression. In the latter, I have to use ==, or else it does the wrong thing. What is best practice?
- The HUG documentation insists that colors have to be given as hex strings, but in Tick Tock Rocket I tried color names on a whim, and it works just fine for me. Can I rely on it?
Got more to ask, of course, but these are directly related to the game in progress. Enjoy, and let me know how you like it.
|
|
|
Post by Pjot on Oct 9, 2019 9:04:12 GMT 1
Thanks felixp7, Again your game works perfectly fine. In your code I saw one Pythonesk typo at line 90, the colon ":" doesn't need to be there. On the other hand, the colon separates statements and is valid BaCon syntax, so it doesn't hurt either. Regarding your questions: - Your observation is correct: in BaCon, equations are only parsed to C syntax in case of IF, ELIF, WHILE, REPEAT and the inline IIF/IIF$ statements. To allow the RETURN statement to parse equations is an interesting idea though. I can look into this functionality for the upcoming 3.9.3 release. As for now, you can also work around it by using an assignment in the RETURN statement, for example:
RETURN x=1==2
- In GTK, color names are indeed a valid practice. It is my understanding that you can use the X11 definitions for colors without problems.
Best regards Peter
|
|
|
Post by felixp7 on Oct 10, 2019 17:17:09 GMT 1
Thanks for the answers! That's all good to know. Unfortunately, the third game in the series will be late due to technical difficulties. And one of them is that I'm not sure how to draw a convincing mountain without filled polygons (also houses look ugly). So I'll have to use sprites instead. The window is now fixed in size anyway. Of course, I could just import the Gtk functions I need, but it would take effort, and sort of defeat the purpose.
|
|
|
Post by felixp7 on Oct 12, 2019 8:46:43 GMT 1
All right, after being busy and sick, I wasted half a day trying to get sprites to work only to run into a strange issue (described in another thread). So to keep things moving, I went back to my first attempt and completed it such as it was. The mountain tile is unfinished, and I only had time for superficial testing, but it's playable. Enjoy! Edit: thanks to prompt and helpful responses in the other thread, I can now show you the alternate implementation with sprites. Gameplay should be identical. Have fun!
|
|
|
Post by bigbass on Oct 13, 2019 6:37:47 GMT 1
Hello felixp7
Thank you for porting your work to bacon! its a great way to learn by seeing different languages side by side
this is very helpful and useful
and its very good to see you got it working quickly in bacon
Joe
|
|
|
Post by felixp7 on Oct 13, 2019 7:22:36 GMT 1
Indeed, it went very quickly and easily! BaCon turns out to be very well designed if you give it half a chance. And porting games is fun! I do it all the time. It's instructional as you pointed out, and also helps reach new audiences. The originals have been largely ignored after an initial good reaction, and that was disappointing. People seem to think Python is only for utilities.
|
|
|
Post by felixp7 on Oct 15, 2019 15:46:35 GMT 1
Anyway, onward to the 4th game in the series. Unlike all others, this is a clone of a well-known game, and the most popular variant at that. Like some of the others, it came out smaller than the original Python code, which doesn't cease to amaze me. As a silly mistake, I tried to use RETURN instead of EXIT SUB, and it didn't go well, but that was easy to fix. Have fun then!
|
|
|
Post by Pjot on Oct 15, 2019 18:29:32 GMT 1
Thanks felixp7,
All works flawlessly, as usual!
BR Peter
|
|
|
Post by felixp7 on Oct 16, 2019 12:02:54 GMT 1
Awesome! Only one game left now, and it has much in common with the first. Until then however, here's a question I keep forgetting to ask: how to query the current width and height of a canvas widget in HUG? I tried to peek at the Gtk documentation, but sort of got lost, and a search through the forum didn't help either. It would open up all sorts of interesting possibilities.
|
|
|
Post by Pjot on Oct 16, 2019 17:45:52 GMT 1
Hi felixp7, Ìn the HUG abstraction layer there is no such facility to query the canvas size. Reason is that by default, the main window has a fixed size and cannot change its shape, which also prevents the canvas to get other dimensions than those you have defined yourself. So the idea of HUG was to keep things simple but it comes with a penalty Generally speaking, you would need to obtain the underlying GdkPixbuf and then use the get width and get height functions. However, HUG returns an event box so it can capture mouse events. Therefore, you must an internal HUG structure to get to the GdkPixbuf. First, query the "hug_widget_image(STR$(<CANVASID>))" associative array with your canvas ID to get the image widget. This will return a memory address. Then use the address in GETPROPERTY to get the GdkPixbuf. After that you should be able to get the sizes with the aforementioned functions. HTH Peter
|
|
|
Post by felixp7 on Oct 17, 2019 8:14:19 GMT 1
Oh, all right. I was thinking for when the TABLE option is in use, but that sounds complicated. No wonder I couldn't figure it out myself. Never mind then, for more advanced stuff I can always use FLTK. Thanks anyway! Now for the last game in the series. This one is noticeably bigger than the others. It also reuses the most pieces, which made it quick to port. And yes, I decided to treat the two sides as distinct data types rather than mess with pointers to arrays of records. Speaking of which, I like the way RECORD works in BaCon. Just one of many thoughtful details in the language. Anyway, enjoy!
|
|