Join us on Discord!
You can help CodeWalrus stay online by donating here.
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - annoyingcalc

#1
Site News & Announcements / Re: The end of CodeWalrus?
August 14, 2017, 12:07:00 AM
I'd be willing to chip in some money to keep it up.
#2
I'm 6th cousins once removed with Johnathon Toews, apparently.
#3
I'd say that I'm late in development. Progress is slow, but here's my todo:
Fix enemy collision detection
Finish the option to toggle animations (animations are the biggest source of lag, but they also control a few things like when to spawn in items, so I need to make that code independent of animations)
Add more enemies
Add more blocks
Add the ability to specify a name for a custom level
Final bugfixes

Then I'll be done and release it. I'll post screenshots of with/without animations soon if anyone wants it
#4
Good idea. The only problem I can see is that for it to work I'd have transfer the main buffer to the back buffer every time which might take longer than just drawing all of them. I'm going to go check the Axe documentation.

EDIT: It appears that would be much slower.
#5
Progress is slowly being made. I have sped the program up significantly, but the physics are still pretty pathetic. The biggest slowdown currently is the animation function because it draws animated blocks every program tick. I can't think of any way to speed this up, so I'll have an option to disable animations.

Otherwise, the biggest task left ahead of me is making the physics not suck.

Also, I'm working on adding enemies, items, and tiles. If anyone has any suggestions for physics, I'd be open for help.

(My problem is I can't seem to create a realistic way for mario to move)
#6
They are koopas Actually, they're goombas. Also, just wondering, does anyone have any tips on how to specify a name to save/load a level from?
#7
Currently, it's a fixed height of 16 blocks.  Speed isn't the issue, it's the physics making it look slow. As for bullets, yes  they are planned along with koopas.
#8
The biggest problem would be that this supports vertical scrolling while Sam Heald's does not.

Update:Working on the physics (the cause of the program looking slow)

Edit:As for a level editor, the only thing that needs to be done is the ability to name the levels.
#9
I'm not sure about levels from Super Mario 2.0. If I do add it, it'll be probably be after it's released.

As for Yoshi, most likely not.
#10
Quote from: DJ Omnimaga on October 24, 2015, 08:23:17 PM
By the way, will Mario have an extra white outline when walking on dark backgrounds?
Once I implement them, yes
#11
Yeah, what happened was that I haven't updated the enemy code to do that. I have been focusing on better collision detection, because I changed how the map is stored.
#12
I will change the pipe sprites when I get a chance.
#13
The biggest slowdown is that I have somethings completely redraw the map. I will be adding a simple function to draw the tile at a certain position to fix this.
Example of this is when an enemy falls upside down off the screen, the blocks behind him need to be redrawn.

Mario's physics have a bit to do with it as well
#14
Of course not lol This is supposed to feel like a mario game
#15
The glitches with the enemies don't happen on calculator. For some reason they occur in wabbit emu.

SCREENSHOTS!

Powered by EzPortal